Loading ToolBench
MCP server providing SonarLint code analysis for Claude Desktop and other MCP clients
The SonarLint MCP server demonstrates solid tool design with clear action verbs, comprehensive descriptions, and well-structured input schemas. All 7 tools have explicit registrations with descriptions and parameter documentation. Descriptions are generally 150-300 characters, well within the 10-1024 range, and include WHEN to use guidance (e.g., 'Use after writing or modifying code', 'Use when reviewing several files'). Input schemas use Zod validation with enums for constrained values (severity levels, languages). However, output schemas are not documented in the source code, tool responses are not formally specified, forcing LLMs to infer structure. Error handling is basic (handleToolError wrapper) with no visible recovery guidance. Two write tools (fix_issue, fix_all_issues) lack confirmation/dry-run patterns. Tool naming is strong (verb_noun pattern throughout). Parameter naming is inconsistent: filePath vs filePaths (camelCase), but language enum values are lowercase. The server does not expose API keys as parameters (good), but no audit logging or permission gates are visible.
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.
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 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.
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).
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.
Output schemas not documented. Tools return responses but no formal schema is specified in code (no return type annotations, no documented response structure). LLMs must infer output structure, risking field extraction errors and context waste.
Destructive operations (fix_issue, fix_all_issues) lack confirmation/dry-run patterns. These tools modify files directly with no preview, undo, or user confirmation step. Agents cannot verify fixes before applying them, risking unintended code changes.
Error responses use generic handleToolError() wrapper with no visible recovery guidance. Tool failures return errors but do not tell the LLM what to do next (retry? lookup first? clarify input?). Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
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.
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.
No pagination support for list_rules or check_files results. Large rule lists or multi-file checks could return unbounded arrays, exhausting context window. No limit parameter documented.
No audit logging or permission gates visible. Destructive operations (fix_issue, fix_all_issues) execute immediately without checking agent authority. No trace of who called what tool and when.