Semgrep for code quality
Semgrep's official server is the top pick for code quality because it runs the analysis right where the code is being written. An agent can scan the file it just edited, read the findings, and propose a fix in the same loop, rather than handing a human a report to interpret later.
It leads here on the static-analysis surface: pattern-based scanning that flags insecure and low-quality code, with the option to write custom rules for your own conventions. That tight scan-explain-fix loop, on code the agent already has in context, is what puts it ahead of the platform-oriented and runtime-oriented siblings for catching issues before they ship.
How Semgrep fits
semgrep_scan runs locally against file paths and semgrep_scan_remote against provided code content, both returning findings as JSON the agent can act on. semgrep_scan_with_custom_rule enforces conventions the default rulesets miss, and semgrep_rule_schema plus get_abstract_syntax_tree help write and verify those rules against the code's actual structure. semgrep_scan_supply_chain flags vulnerable third-party dependencies, and semgrep_findings pulls existing results from the AppSec Platform when you are authenticated.
The honest scope: Semgrep analyzes source statically, so it catches what patterns can predict, not what breaks at runtime. SonarQube fits better when you want a quality platform that tracks maintainability and coverage over time with gates, Snyk when dependency CVEs and developer-security scanning across containers is the focus, and Sentry when the question is what actually failed in production rather than what static analysis flags. Reach for Semgrep first when you want fast, rule-backed findings on the code in front of the agent.
Tools you would use
| Tool | What it does |
|---|---|
| semgrep_scan | Runs a Semgrep scan locally on the provided code files (absolute paths) and returns the findings in JSON format. |
| semgrep_scan_remote | Runs a Semgrep scan on provided code content (rather than local file paths) and returns the findings in JSON format. |
| semgrep_scan_with_custom_rule | Runs a Semgrep scan with a custom rule against provided code content, for vulnerabilities not covered by the default rulesets. |
| semgrep_scan_supply_chain | Runs a Semgrep supply-chain scan on a workspace directory to identify third-party (dependency) security vulnerabilities. |
| semgrep_rule_schema | Returns the schema for a Semgrep rule, showing the fields available when writing or verifying a rule. |
| semgrep_findings | Fetches existing security, code-quality, and supply-chain findings from the Semgrep AppSec Platform Findings API (requires authentication). |
| get_supported_languages | Returns the list of programming languages supported by Semgrep. |
| get_abstract_syntax_tree | Returns the abstract syntax tree (AST) for a provided code file in JSON format, to understand its structure. |
| semgrep_whoami | Returns the identity of the currently authenticated user (works with JWTs, not API tokens). |
FAQ
- Can Semgrep enforce custom code-quality rules?
- Yes. semgrep_scan_with_custom_rule runs a rule you write against provided code, semgrep_rule_schema shows the fields available when authoring one, and get_abstract_syntax_tree returns a file's AST so the rule targets real structure. That custom-rule reach is part of why it ranks first for code quality.
- Does Semgrep catch runtime bugs?
- No. It scans source statically with semgrep_scan and semgrep_scan_remote, so it catches what patterns predict, not what breaks in production. Sentry, which ranks fourth here, brings runtime errors and stack traces into view, so the two are complementary rather than substitutes.