# Semgrep MCP > Semgrep gives your AI agent read/write access to its SAST platform. Use it to audit code security findings, update triage statuses on vulnerabilities, and enforce custom semantic rules across your entire codebase. You can pull detailed flaw reports, check compliance metrics, or create new organizational rules without leaving your chat window. ## Overview - **Category:** fort-knox - **Price:** Free - **Tags:** sast, sca, code-security, vulnerability-management, static-analysis, devsecops, compliance-auditing, automated-triage ## Description Look, you don't wanna jump between your chat window and the Semgrep dashboard just to check on some security findings. This MCP Server gives your AI client direct read/write access to the SAST platform. You can audit code vulnerabilities, manage custom rules, and update triage statuses—all without leaving your agent. **To Start:** First, you'll need to scope things out. You can run `list_deployments` to see every monitored deployment slug; this defines where all the subsequent actions take place. Then, use `list_projects` or `get_project` to pull a list of every tracked Semgrep project within that specific environment. **Finding Flaws:** Once you're scoped in, getting an overview is easy. Run `list_findings` to fetch a summary of static analysis security findings for a deployment, showing the severity and file/line number immediately. If you need deep forensic data on one flaw, call `get_finding_details`; this pulls precise info, suggested fixes, and associated CVE links. **Handling Vulnerabilities:** When your agent finds a bug, it can take action right there. Use `update_finding_status` to change the formal state of any reported finding—you'll tell it if it's 'fixed', marked as a 'false_positive', or simply 'ignored'. **Building Custom Rules:** Need to catch a specific bad pattern that Semgrep missed? You can use `create_rule` to write and deploy brand new, custom semantic security rules across your entire codebase. If a rule is no good anymore, you'll run `delete_rule` to remove it from the deployed environment. To see what rules are already live, just ask for `list_rules`, which lists every deployed semantic rule by name and status. **Reporting & Auditing:** For executive reports or overall health checks, pull AppSec performance statistics using `get_metrics`. This delivers compliance data and fix rates. You can also manage the scope of your work by listing all defined organizational deployments with `list_deployments`, which is required for almost every other API call. **Tying It Together:** Your agent handles the flow: it lists projects, gets a summary list of findings, pulls detailed info on the worst offenders, and then updates their status or deploys a new rule to prevent them from happening again. You've got total control over your security posture right in the chat. ## Tools ### create_rule Deploys a new, custom semantic security rule across your enterprise codebases. ### delete_rule Removes an existing custom Semgrep security rule from the deployed environment. ### get_finding_details Retrieves precise information on a single flaw, including suggested fixes and associated CVE links. ### get_metrics Pulls AppSec performance statistics and compliance data for executive reporting. ### get_project Searches for a specific Semgrep project by its exact repository name. ### list_deployments Lists all defined organizational deployments, which are required to scope most other API operations. ### list_findings Fetches a summary of static analysis security findings (severity and file/line number) for a deployment. ### list_projects Lists all monitored Semgrep projects, which track security scan outputs over time in a specific deployment. ### list_rules Lists every deployed semantic rule by name and status across the organization. ### update_finding_status Changes the formal state of a Semgrep finding to 'fixed', 'false_positive', or 'ignored'. ## Prompt Examples **Prompt:** ``` List the most severe unmitigated findings currently breaking our CI/CD pipeline on the 'vinkius/cloud' repository. ``` **Response:** ``` I've fetched the findings list scoped to 'vinkius/cloud'. Currently, there are 2 blockers. 1) Exposed hardcoded AWS Secret Access Key in `auth.py:L45`. 2) Outdated dependency `lodash@4.17.15` in `package.json` vulnerable to prototype pollution. Would you like me to resolve the Lodash one by generating an update commit script? ``` **Prompt:** ``` Mark vulnerability issue ID #58032 as a 'false_positive' using the update finding tool. ``` **Response:** ``` The operation is complete. I've sent the mutation `update_finding_status` for issue 58032 within your deployment. Semgrep now permanently recognizes this event as `false_positive`, and subsequent scans will not flag this specific semantic line match again. ``` **Prompt:** ``` Review the company's Semgrep performance metrics focusing on fix rate. ``` **Response:** ``` I've analyzed your AppSec timeline with `get_metrics`. Your overall Fix Rate for the trailing 30 days is hovering around 83%. The median 'time-to-resolve' for critical SAST vulnerabilities is 3.4 days. This shows strong engagement natively within developer pull requests before merge. ``` ## Capabilities ### List all deployed environments Retrieves the slugs for every monitored deployment, defining the scope for subsequent actions. ### Fetch global security findings Gathers a list of static analysis flaws across an entire deployment, showing severity and file location. ### Get specific vulnerability details Pulls detailed information on a single flaw, including suggested fixes and CVE data. ### Update finding status Changes the state of a reported bug (e.g., false positive or fixed) directly in Semgrep. ### Create custom security rules Allows the agent to write and deploy new semantic rules to catch specific bad coding patterns organization-wide. ### Review compliance metrics Generates executive summaries of AppSec performance, like fix rates and time-to-resolve data. ## Use Cases ### The blocker PR review A developer submits a PR, but the CI fails due to an unparameterized SQL query. They tell their agent: 'What is blocking this merge?' The agent runs `list_findings` scoped to that repo and uses `get_finding_details` on the top flaw, explaining exactly which line needs fixing and generating the patch. ### Clearing up old findings A security engineer knows a finding flagged six months ago is now obsolete due to architectural changes. They instruct their agent to run `update_finding_status` on the specific flaw ID, removing it from the active compliance queue forever. ### Compliance reporting for execs DevOps needs a quick health check before the board meeting. They ask their agent to pull metrics via `get_metrics`. The agent returns a summary showing the overall Fix Rate (e.g., 83%) and average time-to-resolve, perfect for pasting into a presentation. ### Enforcing new standards A team discovers that hardcoding AWS keys is still happening in legacy services. The architect uses `list_rules` to see existing policies, then runs `create_rule` to deploy a new rule blocking any literal string matching 'AWS_ACCESS_KEY'. ## Benefits - Automate findings triage. Instead of manually logging into Semgrep to change a status, use `update_finding_status` to tell your agent to mark an issue as 'false_positive' or 'fixed'. - Deploy rules at speed. When you find a new vulnerability pattern, the agent can write and deploy it instantly using `create_rule`, enforcing security without developer overhead. - Get deep context fast. The `get_finding_details` tool pulls more than just an error message; it gives CVE links and suggested semantic fixes for immediate use. - Audit coverage scope. Use `list_deployments` to see every environment you manage, making sure no production pipeline is blind to new security rules. - Measure compliance without exports. The `get_metrics` tool streams fix rates and time-to-resolve data directly into your chat summary. ## How It Works The bottom line is, it lets your agent talk directly to Semgrep's backend instead of relying on web UI clicks. 1. Enable the Semgrep MCP server in your agent's environment. 2. Supply a standard API Token from your Semgrep Dashboard settings to authenticate access. 3. Run a command through your AI client (e.g., 'List all critical findings for staging') to initiate the security audit. ## Frequently Asked Questions **How do I find out which environments Semgrep is monitoring?** Run `list_deployments`. This tool provides the deployment slug identifier, which you then need to scope all other operations (like fetching findings) against. **Can I update a finding status without knowing the flaw ID?** No. You must first use `list_findings` to get the relevant snippet details and identify the specific flaw, which then gives you the necessary ID for `update_finding_status`. **What if I need a new security rule? Should I use `create_rule`?** Yes. Use `create_rule`. This tool lets your agent write and deploy custom semantic rules, which is the correct way to enforce brand-new corporate standards. **How do I check overall security performance metrics?** Use `get_metrics`. This pulls AppSec stats like Fix Rate and time-to-resolve data, giving you an executive summary without needing to dig through raw findings. **When I use `get_finding_details`, what specific information do I get about a vulnerability?** It gives you precise context, not just severity. You retrieve the exact malicious code block, suggested semantic fixes, and links to CVE data if it's an SCA supply chain issue. **I need to check which repositories are covered by Semgrep; how do I use `list_projects`?** This tool lists every project (repository) currently monitored within a specific deployment. You use this list to define the precise scope for any subsequent finding or rule search. **If a custom security pattern is obsolete, how do I remove it using `delete_rule`?** The `delete_rule` function removes a custom semantic rule from your deployment. It's the direct way to clean up old or unnecessary anti-patterns from the system. **My deployed rules fail; what should I check when running `list_rules`?** Verify that the YAML definitions are structurally sound and that the rule targets the correct file paths. The output helps you confirm if the pattern exists within any monitored codebase. **Can the AI resolve or close findings in Semgrep natively?** Yes. This server supports mutable actions. By invoking `update_finding_status`, your AI agent can shift a specific semantic flaw to 'mitigated', 'fixed', 'ignored', or 'false_positive' updating the registry in real-time. **How can I deploy a new custom SAST rule via chat?** Simply ask the LLM: 'Draft a semantic grep rule to ban hardcoded API keys in Python and deploy it'. The agent will natively format the JSON structure required and call `create_rule`, sending it directly to all repositories. **Do I need to supply a 'Deployment Slug' for every request?** Most API queries require the deployment context. To ensure smooth interactions, just tell the agent your organization slug once (or let it query `list_deployments` to fetch the default one). The agent will remember it for the rest of the conversation loop.