SonarLint MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_qualityA | Check a file for code quality issues — bugs, code smells, security vulnerabilities, and complexity problems. Like having SonarLint in your IDE. Use after writing or modifying code to catch issues early. Returns issues with exact line numbers, severity, and available quick fixes. For multiple files use check_files. |
| check_filesA | Check multiple files for code quality issues in one call — bugs, code smells, security vulnerabilities. Use when reviewing or modifying several files. Supports glob patterns (e.g. 'src/**/*.ts'). When using relative paths or globs, provide basePath so they resolve correctly. Output is compact: only files with issues are shown, clean files get a summary count. For a single file use check_quality. |
| check_codeA | Check code quality of a code snippet or content you have in hand — catches bugs, code smells, security issues, and complexity problems. Use to validate code before writing it to disk, review generated code, or check code you've read into context. No file on disk needed. |
| list_rulesA | List all active code quality rules with ID, name, and severity. Use to look up what a rule means (e.g., S3776 = Cognitive Complexity), discover what issues can be detected, or see which rules apply to a language. Covers bugs, code smells, security vulnerabilities, and security hotspots. |
| health_checkA | Check if the code quality analysis backend is running and healthy. Shows installed language plugins, cache stats, and version info. Use to diagnose when analysis isn't working as expected. |
| fix_issueA | Automatically fix one specific code quality issue. Applies the SonarLint-suggested fix for the issue at the given file, line, and rule. The file is modified directly. To fix all issues in a file at once, use fix_all_issues instead. |
| fix_all_issuesA | Automatically fix all code quality issues in a file that have available quick fixes. Applies all SonarLint-suggested fixes in one operation. Returns what was fixed and what remains (some issues require manual fixes like reducing complexity). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: checking snippets vs single file vs multiple files, fixing all vs single issue, health check, and listing rules. No ambiguity.
All tool names follow a consistent verb_noun pattern (check_code, check_files, check_quality, fix_all_issues, fix_issue, health_check, list_rules) using snake_case.
7 tools is well-scoped for a code quality server, covering analysis, fixing, health, and rule listing without being too few or too many.
Covers core operations: code checking (snippet, single, batch), fixing (all or specific), health monitoring, and rule listing. Minor gaps like per-rule details, but overall complete.