Snyk MCP server: 13 tools inside the Snyk CLI
A security scanner exposed as tools, why authentication is itself a tool, and what the server reports back to Snyk about your agent.
Last verified 1 September 2026 · from The Snyk CLI repository, npm and the server's own tools/list response
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
The Snyk MCP server ships inside the Snyk CLI rather than as a separate package. It starts with snyk mcp -t stdio, and it registers 13 tools covering code, dependency, container, infrastructure and SBOM scanning.
Because the scanner runs where the CLI runs, the tools act on local paths rather than on a hosted API. snyk_sca_scan and snyk_iac_scan both take a path on your machine.
The definitions cost between 5,531 and 9,667 tokens, about 2.8% to 4.8% of a 200,000-token window. Two of the thirteen tools are authentication, and one reports scan outcomes back to Snyk.
What is the Snyk MCP server?
It is Snyk's server for the Model Context Protocol. Snyk scans code and dependencies for vulnerabilities, so a connected agent can check its own output before proposing it.
The scanning surface is broad for thirteen tools: static analysis of source, open-source dependency scanning, container images and infrastructure-as-code files. It also covers an existing SBOM, the software bill of materials for a project, and an AI bill of materials for Python projects.
Two tools are about the session rather than about scanning. snyk_auth authenticates, snyk_logout clears the stored token, and snyk_trust marks a folder as safe for the scanner to read.
It is strongest in code, tests and review, touches CI and release through container and infrastructure scanning, and reaches nothing in production, agent observability or cost.
| Part of the work | What Snyk has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Static analysis, dependency scanning, package health | Yes. Core strength. Source, dependencies and license issues are all reachable as tools |
| CI & release | Container images, infrastructure-as-code, SBOM | Partial. Artifacts headed for release can be scanned; there are no pipeline or deployment tools |
| Production observability | None | No metrics, logs or traces. A running service is out of scope |
| Agent observability & evals | None for your agents | No traces or evaluations. snyk_send_feedback reports scan outcomes to Snyk, not to you |
| AI cost management | None | No spend data of any kind |
For an agent, Snyk answers whether something is safe to ship. It can scan the file it just wrote, the image built from it and the Terraform beside it. It cannot tell you what the deployed service is doing, so it belongs beside a telemetry connector rather than instead of one.
What can an AI agent do with Snyk?
| Task | Tools | Works | Watch out for |
|---|---|---|---|
| Check code the agent just wrote | snyk_code_scan | Yes | Static analysis runs locally, so the path has to be trusted first |
| Check dependencies for vulnerabilities | snyk_sca_scan snyk_package_health_check | Yes | The scan description asks for an absolute path in capitals |
| Decide whether an upgrade will break | snyk_breakability_check | Yes | It is an assessment of a version upgrade, not a test run |
| Scan a container image | snyk_container_scan | Yes | Covers OS packages and application dependencies inside the image |
| Scan infrastructure files | snyk_iac_scan | Yes | Terraform, Kubernetes and other formats, including plan files |
| Check an existing SBOM | snyk_sbom_scan snyk_aibom | Yes | Snyk matches SBOM components only by PackageURL identifier |
| Find where a vulnerability is running | Grafana, Datadog or Dynatrace | No, separate server | Snyk scans artifacts, never a live process |
snyk_trust is the gate in front of everything else. Its own description says it should be run only when the user instructs it, because it grants the scanner access to a folder.
13 tools registered, all on by default
- Source1
snyk_code_scan- Dependencies3
snyk_sca_scansnyk_package_health_checksnyk_breakability_check- Artifacts4
snyk_container_scansnyk_iac_scansnyk_sbom_scansnyk_aibom- Session3Write
snyk_authsnyk_logoutsnyk_version- Access1Write
snyk_trust- Reporting to Snyk1Write
snyk_send_feedback
Groups are a reader's map; the server registers one flat list of 13. Counted on 24 August 2026 from the released CLI.
What connecting costs before the first question
A context window is the amount of text a model can hold at once, and connecting uses some of it before the agent asks anything. Every tool the server registers sends its name, description and input schema to the model when the session starts. The tool list is charged whether or not a single tool is called.
13 tools cost between 5,531 and 9,667 tokens, about 2.8% to 4.8% of a 200,000-token window.
Schemas carry most of it. Descriptions average 432 characters and schemas average 1,405, because a scan tool has to describe every option the CLI accepts.
| Tool set | Tools | Tokens (GPT-5.6, GPT-5.5) | Tokens (GPT-4, GPT-3.5) | Tokens (Claude Haiku 4.5 to Opus 5) | Share of a 200,000-token window |
|---|---|---|---|---|---|
| Every tool, as registered | 13 | 5,607 to 6,798 | 5,531 to 6,807 | 7,268 to 9,667 | 2.8% to 4.8% |
Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted 24 August 2026 from tools/list on the released CLI 1.1306.4. It was started with snyk mcp -t stdio locally.
Registration is static, so no Snyk account was involved. Figures cover name, description and input schema.
The two models in column one share the o200k_base encoding, so they get one count. The spread is formatting, about 21%. Reasoning tokens are output, spent per request. The tool list is input, charged once at connection.
The Claude figures are measured rather than encoded. Anthropic publishes no local tokenizer. So the definitions were sent to the API's count_tokens endpoint, and a no-tools baseline was subtracted. The range covers two tokenizer generations rather than two serializations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a third.
Snyk MCP server limits: where answers come back incomplete
The limits below follow from the server living inside a CLI that has its own session and its own trust list.
The agent says: “The scan came back clean.” It may not have been authenticated.
snyk_auth exists because tools report an unauthenticated state rather than failing loudly. Its own description says to use it when a Snyk tool reports that the user is not authenticated.
An agent that reads that message as a result rather than an error can report a clean scan that never ran.
Guard: Authenticate the CLI before connecting, and have the agent state which scan tool it called.
The agent says: “I have enabled scanning for that directory.” It granted access to the scanner.
snyk_trust marks a folder as trusted so Snyk may scan it. The tool's description says in capital letters that it should be run only if instructed to do so.
Guard: Treat any snyk_trust call as a decision you make, not one the agent makes for convenience.
One tool reports your run back to Snyk.
snyk_send_feedback reports the change in Snyk issues for a single run, and its description names a preventedIssuesCount field for cases where the model avoided introducing a vulnerability.
Guard: Decide whether that reporting is acceptable before connecting, because the tool is registered by default.
How to configure Snyk MCP for agents
- 1
Authenticate before connecting if you can
An existing CLI session avoids the agent calling
snyk_authmid-conversation, which opens an authentication flow the agent cannot complete alone. - 2
Understand
snyk_trustIt marks a folder as safe to scan, and its own description asks the model to run it only when instructed.
- 3
Decide about
snyk_send_feedbackIt reports the change in issue counts from a run back to Snyk, including a count of issues the model prevented.
- 4
Use absolute paths
The dependency scan's description asks for one in capital letters, which is a strong hint that relative paths cause failures.
Paste this into your agent’s instructions
Scan results look authoritative and their scope is invisible in the answer. The block makes the agent name the path and the scan type.
When you answer using Snyk MCP tools, state: - The absolute path or image you scanned, and which scan you ran. Code, dependency, container and IaC scans differ. - Whether the folder was already trusted, or whether you called snyk_trust to make it so. - Whether you called snyk_auth, snyk_logout or snyk_send_feedback. These change session or send data. Never state that data does not exist. State that the scan above returned no findings. Write your answer in ASD-STE100 Simplified Technical English. Use short sentences with one idea in each.
Do you need the MCP server at all?
Not for a pipeline scan. Snyk's own CLI is the direct alternative. Running snyk test in a terminal produces the same findings without spending context.
The connector earns its place inside the loop. An agent that can scan the file it just wrote, before proposing it, is doing something a separate terminal step does not.
At 5,531 tokens the standing cost is small, so the decision is about trust and reporting rather than about context.
Connect it when the agent writes code. Use the CLI directly for scheduled or pipeline scanning.
Snyk MCP server setup
There is no separate package to install. The Snyk CLI is the server, and snyk mcp -t stdio is the whole command.
Authentication reuses the CLI's stored token, so a machine where snyk auth has already run needs no credential in the configuration file.
Claude Code
No credentials appear in the configuration. The CLI's own stored token is used, and snyk_auth handles the browser flow if there is none.
claude mcp add-json "snyk" '{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}'Cursor
In ~/.cursor/mcp.json. Again no credentials here: authorize once with snyk auth in a terminal.
{"mcpServers":{"snyk":{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}}}Codex CLI
Codex reads TOML, so the JSON blocks above will not transfer. No credentials belong here either.
[mcp_servers.snyk] command = "npx" args = ["-y", "snyk", "mcp", "-t", "stdio"]
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Claude Desktop
macOS ~/Library/Application Support/Claude/claude_desktop_config.json. Windows %APPDATA%\Claude\claude_desktop_config.json. There is no CLI. Edit through Settings, Developer, Edit Config.
Quit and restart fully for changes to load. Paths in args must be absolute. Logs at ~/Library/Logs/Claude/mcp.log.
No credentials appear in the file. The Snyk CLI's stored token is used, so authorize once with snyk auth first.
{"mcpServers":{"snyk":{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}}}Gemini CLI
~/.gemini/settings.json globally, or .gemini/settings.json per project. Key mcpServers. CLI: gemini mcp add.
No credentials appear in the file. The Snyk CLI's stored token is used, so authorize once with snyk auth first.
{"mcpServers":{"snyk":{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}}}VS Code Copilot
.vscode/mcp.json per workspace, or your user profile. CLI: code --add-mcp.
No credentials appear in the file. The Snyk CLI's stored token is used, so authorize once with snyk auth first.
{"servers":{"snyk":{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}}}The key is `servers`, not `mcpServers`. VS Code is the only client that uses that name, and copying a config from anywhere else fails silently.
Windsurf
~/.codeium/windsurf/mcp_config.json, which is the path Windsurf documents. Key mcpServers, the same JSON shape as Cursor, carrying the same CLI session, with no credential in the file.
Zed
~/.config/zed/settings.json, carrying the same CLI session, with no credential in the file, as in the blocks above.
The key is `context_servers`. Zed does not call them MCP servers in config, so searching its settings for mcp finds nothing.
Google Antigravity
~/.gemini/config/mcp_config.json globally, or .agents/mcp_config.json per project. Key mcpServers. There is no CLI. Use the /mcp overlay in the editor. Supports stdio, streamable HTTP, SSE and websocket.
No credentials appear in the file. The Snyk CLI's stored token is used, so authorize once with snyk auth first.
{"mcpServers":{"snyk":{"command":"npx",
"args":["-y","snyk","mcp","-t","stdio"]}}}Amp (Sourcegraph)
~/.config/amp/settings.json or .amp/settings.json, carrying the same CLI session, with no credential in the file. The amp mcp CLI covers approve, doctor and oauth.
The key is `amp.mcpServers`, namespaced. A bare mcpServers block is ignored.
Cline
~/.cline/mcp.json per the docs. The source also reads ~/.cline/data/settings/cline_mcp_settings.json. Key mcpServers, standard JSON shape, carrying the same CLI session, with no credential in the file. Supports stdio, streamable HTTP and SSE.
Goose (Block)
~/.config/goose/config.yaml, carrying the same CLI session, with no credential in the file.
YAML, and servers are called `extensions`. Goose does not use the MCP vocabulary in config at all. Add one interactively with goose configure, or per session with goose session --with-extension.
Kiro (AWS)
.kiro/settings/mcp.json per workspace, or ~/.kiro/settings/mcp.json globally. Key mcpServers, standard JSON shape, carrying the same CLI session, with no credential in the file.
Warp
~/.warp/.mcp.json or .warp/.mcp.json. Key mcpServers, standard shape, carrying the same CLI session, with no credential in the file. Also addable through the /agent-add-mcp skill.
JetBrains Junie
.junie/mcp/mcp.json per project, or ~/.junie/mcp/mcp.json. Key mcpServers, carrying the same CLI session, with no credential in the file. Use /mcp in the CLI to manage.
Roo Code
.roo/mcp.json per project. The global file is mcp_settings.json, opened from the Roo Code MCP settings view with Edit Global MCP. Key mcpServers, carrying the same CLI session, with no credential in the file.
Continue
.continue/mcpServers/*.yaml, one file per server, carrying the same CLI session, with no credential in the file.
YAML, and `mcpServers` is a list, not an object. Every JSON client keys servers by name. Continue takes an array, so a converted config will not parse.
Trae
.trae/mcp.json per project, or paste into the UI under Raw Config (JSON). Key mcpServers, standard shape, carrying the same CLI session, with no credential in the file.
Devin
Devin has no config file to edit. Servers are added through a web form in the settings UI, and Devin's documentation states you do not need to write or paste JSON. The block below is the shape those fields describe, shown for reference. Either route uses the same CLI session.
Installed CLI rather than npx
If the CLI is already installed, call it directly. It authorizes from its own stored session.
{"mcpServers":{"snyk":{"command":"snyk",
"args":["mcp","-t","stdio"]}}}Read-only access, permissions and security
snyk_trustwidens what can be readIt marks a folder as safe for the scanner, and its description tells the model to run it only when instructed.
Two tools change the session
snyk_authauthenticates the machine andsnyk_logoutclears the locally stored token, which affects the CLI outside the agent as well.One tool sends data to Snyk
snyk_send_feedbackreports the change in issue counts for a run, including a count of vulnerabilities the model prevented in new code.Scans run locally
That keeps source on your machine, and it also means the agent can point a scan at any path the trust list allows.
Troubleshooting
- A scan reports that you are not authenticated
- Run
snyk authin a terminal, or let the agent callsnyk_auth, which exists for exactly this case. The token is stored by the CLI, not by the agent. - A dependency scan fails on a valid project
- The tool's description asks for an absolute path in capital letters. A relative path is the usual cause.
- The scanner refuses to read a folder
- The folder is not trusted.
snyk_trustgrants access, and its own description asks that it be run only on instruction. - An SBOM scan finds nothing in a real SBOM
- Snyk matches a component only when it carries a PackageURL identifier. An SBOM without those identifiers scans clean regardless of what it lists.
Snyk MCP server: Reference
| Item | Value |
|---|---|
| Status | Snyk CLI 1.1307.0 · tools captured on 1.1306.4 · repository pushed 1 September 2026 |
| Adoption | 5,644 stars · 699 forks · 100 or more releases · repository created 30 October 2015 |
| License | Apache-2.0, per the CLI's LICENSE file |
| Package | snyk on npm; the server is snyk mcp -t stdio |
| Auth | The CLI's stored token, or the snyk_auth tool |
| Tools | 13 in the default full profile. Snyk documents --profile=lite|full|experimental, and lite carries 7 |
| Session tools | snyk_auth, snyk_logout, snyk_trust |
| Outbound reporting | snyk_send_feedback, issue-count deltas per run |
| Context cost | 5,531 to 9,667 tokens |
What engineers report
The Snyk CLI repository carries 5,644 stars, 699 forks and 100 or more releases since 30 October 2015. The signals worth reading here concern the MCP mode rather than the CLI.
| What was checked | What it shows |
|---|---|
| Stars on the CLI repository | 5,644 |
| Last push | 24 August 2026 |
| Version | 1.1307.0 on npm · tools captured on 1.1306.4 |
| License | Apache-2.0, per the LICENSE file |
Tools returned by tools/list | 13 |
| Average description | 432 characters per tool |
| Average schema size | 1,405 characters per tool |
Repository facts from the GitHub API and npm, retrieved 24 August 2026. GitHub reports the license as unrecognized; the LICENSE file itself states Apache-2.0. Tool counts and sizes come from the CLI's own tools/list response.
Should you connect an agent to Snyk?
Yes. Best for a machine where snyk auth has already run, so the agent never has to start an authentication flow.
- Strongest fit
- Teams whose agents write code and who want it scanned in the same loop rather than in a later pipeline stage.
- Main advantage
- Scans run locally through a CLI most teams already have, so nothing new is deployed.
- Main weakness
- No view of running systems, so a vulnerability's real exposure has to be established elsewhere.
- Operational risk
snyk_trustwidens scanner access andsnyk_send_feedbackreports run outcomes to Snyk, both enabled by default.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.
See agent observabilityFrequently asked questions
How many tools does the Snyk MCP server have?
13, all on by default. Counted from the CLI's own tools/list response on version 1.1306.4, on 24 August 2026.
Is there a separate package to install?
No. The server is a mode of the Snyk CLI, started with snyk mcp -t stdio. If the CLI is installed, the server is too.
Where do scans run?
Locally, where the CLI runs. That keeps source on your machine and means tools take local paths rather than a hosted project ID.
What does snyk_send_feedback do?
It reports the change in Snyk issues for a single run back to Snyk, including a count of issues the model prevented in new code.
Why does a scan say I am not authenticated?
The CLI has no stored token. Run snyk auth in a terminal, or let the agent call snyk_auth, which exists for that case.