Semgrep MCP: The Complete Guide (2026)

TL;DR + what you actually need

• One command, no account: uvx semgrep-mcp runs the server locally over stdio. The scanning tools use the open-source Semgrep engine — no token, no login, no data leaves your machine.
• One line for Claude Code: claude mcp add semgrep uvx semgrep-mcp. That is the verbatim command from Semgrep’s README.
• One optional secret: SEMGREP_APP_TOKEN — only needed for the semgrep_findings tool, which reads historical results from the Semgrep AppSec Platform. Skip it and everything else still works.
• The honest caveat: the agent scans only when it decides to. MCP makes the tool available; it does not guarantee the model uses it. Plan for that (see the noise problem).

Semgrep is a fast, deterministic static-analysis tool for finding security bugs in source code. This server hands that engine to an AI agent so it can scan the code it just wrote. It fits squarely in the site’s security lane — see npm supply-chain attacks and the OWASP MCP Top 10 for the wider threat picture MCP itself introduces.

What it is (one sentence)

The Semgrep MCP server is Semgrep’s official Model Context Protocol server — a process that exposes Semgrep’s static-analysis engine as callable tools, so any MCP client (Claude Code, Cursor, VS Code, Windsurf, ChatGPT, or your own agent) can scan code for vulnerabilities and read the findings inline.

“Static analysis” means it inspects source code without running it, matching patterns that correspond to bugs — a SQL query built by string concatenation, a subprocess call with shell=True, a hard-coded secret. Semgrep is deterministic: the same code and rules always produce the same findings, which is exactly the property a probabilistic language model lacks. That pairing is the whole point — the model writes and reasons, Semgrep provides the ground truth about security patterns.

Why it exists

AI coding assistants generate more code, faster, than any human review process was built for — and they learned from public repositories that are full of insecure patterns. Semgrep’s own framing is “giving AppSec a seat at the vibe-coding table”: the security scan should happen the moment code is written, in the editor, not three days later when a CI pipeline fails or a pentester files a ticket.

Before this server, that loop was manual — generate code, switch to a terminal, run semgrep scan, read a report, switch back, paste the finding to the model, ask for a fix. The MCP server collapses all of that into one conversation. The agent scans, reads the JSON findings itself, and rewrites the offending code in the same turn. That is the failure mode it fixes: the context-switch tax that made people skip the scan entirely.

Install (every client) — verified commands

These are copied verbatim from the official semgrep/mcp README. The package is published to PyPI as semgrep-mcp; the quickest path is uv, which runs it without a manual install step.

Run it directly

# Run over stdio with uv (recommended)
uvx semgrep-mcp

# ...or as a Docker container
docker run -i --rm ghcr.io/semgrep/mcp -t stdio

On stdio the process shows no output and looks like it is hanging. That is expected — it is waiting to speak JSON-RPC over standard input and output to its client.

Claude Code

One line, straight from the README:

claude mcp add semgrep uvx semgrep-mcp

Restart Claude Code, run claude mcp list to confirm the server is connected, and the Semgrep tools appear in the tool catalogue. Full flag reference lives at /clients/claude-code.

Cursor, VS Code & Windsurf

Add this to Cursor’s ~/.cursor/mcp.json (or the project-local .cursor/mcp.json):

{
  "mcpServers": {
    "semgrep": {
      "command": "uvx",
      "args": ["semgrep-mcp"]
    }
  }
}

VS Code / Copilot uses the same shape nested under an mcp.servers key in User Settings (or .vscode/mcp.json); Windsurf uses the same block in ~/.codeium/windsurf/mcp_config.json. A tip from Semgrep’s docs: add a rule such as “Always scan generated code with Semgrep for security vulnerabilities” to your .cursor/rules so the agent reaches for the tool without being asked each time.

The tool surface

The server exposes a compact set of tools, grouped by what the agent is trying to do. All names below are from the server’s API reference.

It also ships a write_custom_semgrep_rule prompt and two resources (semgrep://rule/schema and semgrep://rule/{id}/yaml) for pulling rule definitions. The opinionated takeaway: for day-to-day agent use you will live in security_check. It is the “is this code safe before I commit it” button, and its own description instructs the model to fix anything it finds. The rest are for when you need control — a custom rule, a structural query, or a look back at what past scans already flagged.

Smallest end-to-end example

First, a sanity check that the binary is wired up. The --help output is the fastest confirmation the package installed:

$ uvx semgrep-mcp --help
Usage: semgrep-mcp [OPTIONS]

  Entry point for the MCP server

  Supports both stdio and sse transports.

Options:
  -v, --version                Show version and exit.
  -t, --transport [stdio|sse]  Transport protocol to use (stdio or sse)
  -h, --help                   Show this message and exit.

Now the real loop. In Claude Code, after the agent writes a small Flask handler, you ask it to check its own work:

You: Scan the login handler you just wrote for security issues.

Claude: Running security_check on the file…
  → 1 finding (ERROR): formatted SQL string is tainted by
    request input — SQL injection risk.
    rule: python.flask.security.injection.tainted-sql-string
    line 14: db.execute(f"SELECT * FROM users WHERE name = '{name}'")

  Fixing: switching to a parameterized query.
    db.execute("SELECT * FROM users WHERE name = %s", (name,))

The finding shape above is representative of Semgrep’s JSON output (check ID, severity, file, line, message). The point is the round trip: the model wrote code, the security_check tool returned a deterministic finding, and the model applied the standard fix — all in one turn, no terminal, no CI wait.

Local, hosted, or the AppSec Platform

Three deployment shapes exist, and picking the right one is most of the decision:

• Local (stdio) — the default. uvx semgrep-mcp or the Docker image. Your client launches it as a subprocess; code is scanned on your machine and never leaves it. This is the right answer for almost everyone, and the one this guide installs.
• Hosted (streamable-HTTP). Semgrep runs an endpoint at https://mcp.semgrep.ai/mcp (plus a legacy /sse path) so you can connect without installing anything. Useful for a quick trial or a thin client. Semgrep labels it experimental and warns it “may break unexpectedly” — do not build a CI gate on it.
• AppSec Platform (token). Set SEMGREP_APP_TOKEN and the semgrep_findings tool can read the historical findings your organization’s past scans uploaded to Semgrep’s cloud — “show me the open criticals in this repo.” This layers on top of either transport; it does not replace local scanning.

The distinction the docs blur: the local tools run the open-source engine and are free; the platform tool needs an account. If you only want “scan what I just wrote,” you never touch a token.

Recipes

Recipe 1 — Pre-commit guardrail

“Before you commit, run security_check on every file you changed and fix anything it flags.” This is the headline use case: the agent scans its own diff and self-corrects. Pair it with a .cursor/rules or Claude Code project instruction so it happens by habit, not by memory.

Recipe 2 — Enforce a house rule

“We ban pickle.loads on untrusted input. Write a Semgrep rule for it and scan the codebase.” The agent calls semgrep_rule_schema, writes the rule, then runs semgrep_scan_with_custom_rule. Your organization’s tribal knowledge becomes an executable check in one prompt.

Recipe 3 — Triage the backlog

“List the top 10 open critical findings in this repo and propose fixes.” With SEMGREP_APP_TOKEN set, semgrep_findings pulls existing platform results scoped to the current repository, and the agent drafts remediation for each. This reads history; it does not run a fresh scan.

Recipe 4 — Understand before you touch

“Show me the AST of this parser so we can see how user input flows through it.” get_abstract_syntax_tree gives the model a structural view instead of a wall of text — helpful when it is reasoning about taint flow before proposing a refactor.

What we got wrong

Three assumptions that cost us time, in the spirit of writing down what actually burned us:

• We assumed the agent would scan automatically. It does not. The tool is available, but the model calls it only when it decides the task warrants it — which, mid-refactor, it often does not. The fix is an explicit project rule, or moving to the Hooks layer (more in the bigger picture).
• We assumed semgrep_findings ran a scan. It does not — it fetches past results from the AppSec Platform. To scan new code you want security_check or semgrep_scan. Reading the tool descriptions, not the names, saves this mistake.
• We assumed the standalone repo was the live project. In 2026 Semgrep folded MCP support into the main semgrep binary and archived the standalone semgrep/mcp repository. The uvx semgrep-mcp package and the Docker image still install and run the server, but new development happens in the main binary and in Guardian. Install with confidence; just know where the source moved.

Common mistakes (from the issue tracker)

The noise problem (and the “will it even scan” problem)

Two criticisms are fair, and pretending otherwise would be a disservice.

False positives are real. Every SAST tool flags things that are not exploitable in context, because exploitability depends on sanitizers, framework protections, and reachability that static analysis cannot fully see. Reviews of Semgrep cite false-positive volume, slow scans on very large codebases, and coverage gaps as recurring pain points — the same reasons the broader community has experimented with putting an LLM in front of Semgrep purely to filter noise (a real thread on r/devsecops describes exactly that). In an agent loop, a noisy finding is worse than a wasted minute: the model may “fix” a non-bug and introduce a real one. Treat findings as input to judgment, not gospel.

An agent can just… not scan. This is the subtler issue, and Semgrep names it directly. In their words, “protocols like MCP make security tools available to AI, but they don’t ensure they’re actually used.” A stochastic model will sometimes skip the scan, especially when it is confident (and confidently wrong). If your security posture depends on the model choosing to call security_check, your posture is probabilistic. That is the exact gap the Hooks/Guardian layer closes by running the scan deterministically on every edit — see below.

Who it is for / not for

Community signal

Semgrep announced the server itself, framing it as their entry into securing AI-generated code:

In practice, developers reach for it as one engine among several. A project shared on r/mcp wired Semgrep alongside Gitleaks, OSV-Scanner, and others into a single pass/fail gate for scanning MCP server repos — and the author’s own question, “are the findings noisy or useful?”, is the honest one. That tension recurs everywhere Semgrep shows up: fast and deterministic, but you own the triage.

The sharpest critique comes from Semgrep’s own security team, who published a deliberately skeptical take on the MCP hype. Their line — “bringing an untrusted MCP server into your environment is exactly like installing a malicious VS Code extension” — is a useful reminder that the protocol is a new attack surface, not just a convenience. (Their scanner is the friendly case; the same channel can carry prompt-injection payloads in a hostile one.)

The verdict

The bigger picture

The MCP server was Semgrep’s first move into agent security; it is no longer the last word. The industry lesson — that a tool the model may call is not the same as a control that always runs — pushed Semgrep toward Hooks (deterministic scans that fire on file edits and when an agent loop completes) and then Guardian, a plugin that bundles the MCP server, Hooks, and Skills into one install for Claude Code, Cursor, Copilot, VS Code, Codex, and more. Guardian scans every file an agent generates and prompts it to regenerate until the code comes back clean.

So the mental model for 2026: the MCP server is the interoperable, any-client primitive — reach for it when you want Semgrep in a custom agent or a client Guardian doesn’t cover, or when you want prompt-driven scanning. Guardian/Hooks is the reliability layer when your agent is one Semgrep supports and you want the scan to be non-optional. Both run the same engine; they differ in when the scan fires. For the wider question of trusting MCP servers at all, our OWASP MCP Top 10 write-up is the companion read, and the best-of list puts Semgrep in context with its neighbors.

Frequently asked questions

Glossary

SAST

Static Application Security Testing — finding bugs by analyzing source code without running it.

Static analysis

Inspecting code as text/structure rather than executing it; deterministic by nature.

MCP

Model Context Protocol — the JSON-RPC standard that lets any AI client call any tool server.

stdio transport

The server runs as a local subprocess, talking JSON-RPC over standard input/output.

streamable-HTTP

A remote transport for MCP over HTTP; how you reach the hosted mcp.semgrep.ai endpoint.

Rule

A Semgrep pattern that matches a class of bug; the registry ships thousands.

Finding

A single rule match in your code — check ID, file, line, severity, message.

False positive

A finding that is not actually exploitable in context; the tax every SAST tool charges.

AST

Abstract Syntax Tree — the parsed structure of code, used to reason about data flow.

SEMGREP_APP_TOKEN

Credential for the Semgrep AppSec Platform; only the findings tool needs it.

Guardian

Semgrep's plugin bundling the MCP server, Hooks, and Skills for AI coding agents.

Hooks

Deterministic scan triggers that run on edits/loop-end, so scanning isn't left to the model.

Sources & links

• Primary: github.com/semgrep/mcp (official repo, README, tool API, install commands) and the semgrep-mcp PyPI package.
• Primary: Semgrep, “Giving AppSec a Seat at the Vibe Coding Table” and the Guardian docs.
• Contrarian: Semgrep, “MCP: Model, Context… Propaganda?” and “Cursor Hooks: Making Security Reliable for Agents”.
• Community: maintainer announcement on @semgrep; multi-engine scanner discussion on r/mcp and false-positive filtering on r/devsecops.
• Internal: /servers/semgrep (canonical entry, install & live tool list), /clients/claude-code, npm supply-chain attacks, OWASP MCP Top 10.