MCP-Server für SonarQube. Ermöglicht es einem LLM-Agenten (Claude Code, Cursor, OpenCode usw.), Projekte zu entdecken, wichtige Metriken abzurufen, den Status des Quality Gates zu prüfen, Probleme mit Schweregrad-/Typ-Filtern zu suchen und Projekte nach dem schlechtesten Wert einer beliebigen Metrik zu sortieren.
Python, FastMCP, stdio-Transport.
Funktioniert mit jeder SonarQube 9.x / 10.x-Instanz (selbst gehostet) sowie mit SonarCloud.
Es gibt bereits einige SonarQube-MCPs aus der Community, aber diese beschränken sich meist auf das Lesen einzelner Projekte. Dieses hier fügt ein projektübergreifendes Ranking (sonarqube_worst_metrics) hinzu – die Operation, die ein Teamleiter tatsächlich während einer Triage-Sitzung durchführt: „Zeige mir die 10 Dienste mit der schlechtesten Testabdeckung in der Organisation“. Alle Tools sind schreibgeschützt und sicher parametrisiert (Pydantic-Eingabevalidierung, Whitelists für Schweregrad/Typ).
Related MCP server: sonarqube-api-mcp
Tool-Annotationen — alle fünf Tools tragen readOnlyHint: True, destructiveHint: False, idempotentHint: True. Nichts kann SonarQube von diesem Server aus verändern.
Strukturierte Ausgabe — jedes Tool gibt ein typisiertes Payload (TypedDict) + eine Markdown-Zusammenfassung zurück, sodass Clients mit und ohne Unterstützung für strukturierte Inhalte eine nutzbare Antwort erhalten.
Strukturierte Fehler — 401 / 403 / 404 / 400 / 429 / 5xx werden auf umsetzbare Hinweise abgebildet (z. B. „Token neu generieren“, „Projekt-Key mit sonarqube_list_projects prüfen“).
Pydantic-Eingabevalidierung für jedes Argument; Schweregrad-/Typ-Filter werden gegen das gültige SonarQube-Enum geprüft, bevor die Anfrage gesendet wird.
Projektübergreifendes Ranking der schlechtesten Metriken — bündelt /api/measures/search-Aufrufe im Hintergrund und sortiert auf- oder absteigend, je nachdem, ob ein höherer Wert für die gewählte Metrik schlechter ist.
Entdeckung
sonarqube_list_projects — paginierte Projektsuche mit optionalem Textfilter
Einblick in einzelne Projekte
sonarqube_project_metrics — Messwerte für ein Projekt (Standard-Set umfasst Bugs / Abdeckung / Code Smells / Ratings / ncloc / Tests / alert_status)
sonarqube_quality_gate_status — Quality Gate-Status + Fehler pro Bedingung
Problem-Triage
sonarqube_get_issues — Problemsuche, gefiltert nach Schweregrad / Typ / Auflösungsstatus
Projektübergreifendes Ranking
sonarqube_worst_metrics — Top-N-Projekte, sortiert nach dem schlechtesten Wert einer Metrik (z. B. schlechteste Abdeckung, die meisten Bugs)
Erfordert Python 3.10+.
# via uvx (recommended — no install, just run)
uvx --from sonarqube-mcp sonarqube-mcp
# or via pipx
pipx install sonarqube-mcpclaude mcp add sonarqube -s project \
--env SONARQUBE_URL=https://sonar.example.com \
--env SONARQUBE_TOKEN=squ_your_token \
--env SONARQUBE_SSL_VERIFY=true \
-- uvx --from sonarqube-mcp sonarqube-mcpOder in .mcp.json:
{
"mcpServers": {
"sonarqube": {
"type": "stdio",
"command": "uvx",
"args": ["--from", "sonarqube-mcp", "sonarqube-mcp"],
"env": {
"SONARQUBE_URL": "https://sonar.example.com",
"SONARQUBE_TOKEN": "${SONARQUBE_TOKEN}",
"SONARQUBE_SSL_VERIFY": "true"
}
}
}
}Überprüfung:
claude mcp list
# sonarqube: uvx --from sonarqube-mcp sonarqube-mcp - ✓ ConnectedVariable | Erforderlich | Beschreibung |
| ja | SonarQube-URL (ohne abschließenden Schrägstrich) |
| ja | Bearer-Token. Generieren unter: Mein Konto → Sicherheit → Token |
| nein |
|
Hinweis zu HTTP-Proxys. Der Client deaktiviert absichtlich die umgebungsbasierte Proxy-Erkennung (trust_env=False), da selbst gehostetes SonarQube normalerweise nur in einem internen Netzwerk erreichbar ist. Wenn Sie eine Verbindung zu SonarCloud oder einem SonarQube herstellen, das hinter einem Unternehmens-Proxy liegt, müssen Sie derzeit die Proxy-Variablen auf Prozessebene entfernen – ein SONARQUBE_TRUST_ENV_PROXY-Schalter ist für ein zukünftiges Release geplant.
„Liste alle SonarQube-Projekte auf, die auf 'einvy' passen“
„Was ist der Quality Gate-Status für einvy:aut_einvy?“
„Zeige mir die Top 10 Projekte mit den meisten Bugs“
„Finde alle BLOCKER / CRITICAL Schwachstellen in einvy:aut_einvy“
„Wie hoch ist die Abdeckung bei einvy:qa_assistant?“
„Top 5 Projekte mit der schlechtesten Abdeckung, die auf die Abfrage 'einvy' passen“
sonarqube_worst_metrics)Höher ist schlechter (absteigend sortiert — mehr ist schlechter):
bugs, code_smells, vulnerabilities, duplicated_lines_density, reliability_rating, security_rating, security_review_rating, sqale_rating, open_issues
Niedriger ist schlechter (aufsteigend sortiert — weniger ist schlechter):
coverage, line_coverage, branch_coverage, test_success_density, tests
Ratings in SonarQube sind numerische Strings von „1“ (A, am besten) bis „5“ (E, am schlechtesten).
Alle Tools sind readOnlyHint: True — nichts kann SonarQube verändern.
Es werden niemals POST / PUT / DELETE-Anfragen aufgerufen.
Eingaben für Schweregrad / Typ / Qualifizierer werden vor dem API-Aufruf gegen SonarQube-Enums validiert, sodass das Tool bei Tippfehlern sofort fehlschlägt, anstatt die API aufzurufen.
Jedes Tool führt einen HTTP-Aufruf an SonarQube durch, außer sonarqube_worst_metrics, das einen Suchaufruf + ⌈Kandidatenpool/100⌉ Bulk-Messwert-Aufrufe durchführt. Die Standardeinstellungen führen zu ≤ 2 Aufrufen.
Antwortzeit eines einzelnen Tools auf einer stabilen SonarQube-Instanz: typischerweise < 500 ms.
Paginierung wird an SonarQube weitergereicht (p + ps Parameter) — kein vollständiges Zwischenspeichern der Ergebnisse im MCP-Server.
sonarqube_worst_metrics begrenzt den candidate_pool auf 500 — bei Instanzen mit Tausenden von Projekten sollten Sie vor dem Ranking mit query= filtern (siehe Tool-Dokumentation).
SonarQube hat kein veröffentlichtes hartes Ratenlimit. Wenn ein 429-Fehler empfangen wird, gibt der Server einen umsetzbaren Fehler aus („Warten Sie 30-60 s vor dem erneuten Versuch; reduzieren Sie page_size“).
git clone https://github.com/mshegolev/sonarqube-mcp.git
cd sonarqube-mcp
pip install -e '.[dev]'
pytestMIT © Mikhail Shchegolev
Search issues for a SonarQube project.
Wraps /api/issues/search. Use the filter parameters to narrow
results — e.g. severities=['BLOCKER','CRITICAL'] for triage, or
types=['VULNERABILITY'] for a security sweep.
Pagination: if has_more is True, call again with page + 1.
SonarQube caps total pagination at 10 000 issues; tighten the filters
if you need to go deeper.
Examples:
- Use when: "Triage top BLOCKER / CRITICAL bugs in einvy:aut_einvy"
→ severities=['BLOCKER','CRITICAL'], types=['BUG'].
- Use when: "Security sweep on the PR"
→ types=['VULNERABILITY'], pull_request='42'.
- Use when: "Show closed issues from March 2024"
→ resolved=True (then post-process by creation_date).
- Don't use when: You want an issue count only — get_issues
always returns full issue objects; for a cheap count call with
page_size=1 and read total from the response.
- Don't use when: You want Security Hotspots — they live on
/api/hotspots/search (this tool rejects them with a clear
error so you won't get silently empty results).
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | Yes | SonarQube project key to query issues for. | |
| severities | No | Filter by severity. Valid values: BLOCKER, CRITICAL, MAJOR, MINOR, INFO. Case-insensitive. Omit to return all severities. | |
| types | No | Filter by issue type. Valid values: BUG, VULNERABILITY, CODE_SMELL. Case-insensitive. Security Hotspots live on a separate API endpoint (not supported by this tool). Omit to return all supported types. | |
| resolved | No | Whether to include resolved issues. Default False — only unresolved issues, which is what an agent fixing code usually wants. | |
| branch | No | Branch name to query (e.g. 'feature/xyz'). If omitted, the project's main branch is used. Mutually exclusive with pull_request. | |
| pull_request | No | Pull request identifier (e.g. '42'). If set, fetches issues raised on the PR decoration analysis. Mutually exclusive with branch. | |
| page | No | Page number (1-based). | |
| page_size | No | Items per page (1-500). SonarQube caps total pagination at 10 000. |
| Name | Required | Description |
|---|---|---|
| project_key | Yes | |
| total | Yes | |
| returned | Yes | |
| page | Yes | |
| page_size | Yes | |
| has_more | Yes | |
| next_page | Yes | |
| by_severity | Yes | |
| by_type | Yes | |
| issues | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds pagination details (has_more, page+1), total cap of 10,000 issues, and notes that Security Hotspots are rejected with an error, providing valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, pagination section, and bulleted examples. Every sentence earns its place without redundancy or excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and output schema, the description covers all necessary aspects: purpose, parameters, pagination, limitations, and usage examples. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds usage examples for parameters (e.g., 'severities=['BLOCKER','CRITICAL']') and clarifies defaults like 'resolved=False', adding extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search issues for a SonarQube project' and wraps '/api/issues/search'. It provides specific verb+resource and distinguishes from siblings like 'sonarqube_list_projects' and 'sonarqube_worst_metrics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use examples, including alternatives for issue counts and Security Hotspots. Examples cover triage, security sweep, and closed issues, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SonarQube projects (components with qualifier TRK).
Use this first to discover which project keys exist before calling
sonarqube_project_metrics or sonarqube_get_issues.
Pagination: if has_more is True, call again with page + 1.
Results are sorted by SonarQube default order (component name ascending).
Examples:
- Use when: "What SonarQube projects contain 'backend' in the name?"
→ query='backend', default pagination.
- Use when: The user gives a project name but not its key.
- Don't use when: You already have the project key and only need its
metrics (call sonarqube_project_metrics directly — one fewer
round trip).
- Don't use when: You need Quality Gate status (that's
sonarqube_quality_gate_status; this tool doesn't return it).
Returns:
dict with keys projects_count / total / page /
page_size / has_more / next_page / query /
projects (list).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional substring to filter project keys or names (case-insensitive). Example: 'einvy' matches any project containing that substring. | |
| page | No | Page number (1-based). | |
| page_size | No | Items per page (1-500). |
| Name | Required | Description |
|---|---|---|
| projects_count | Yes | |
| total | Yes | |
| page | Yes | |
| page_size | Yes | |
| has_more | Yes | |
| next_page | Yes | |
| query | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only operation; description adds pagination behavior (has_more, sort order), and clarifies what the tool doesn't return, exceeding annotation requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded with main purpose, and every sentence provides useful guidance without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence, the description covers usage context, pagination, and examples thoroughly, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value with concrete examples for query and pagination instructions, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists SonarQube projects with qualifier 'TRK', and distinguishes itself from sibling tools by noting when to use it to discover project keys before calling other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use examples (e.g., discover project keys, find projects with substring) and when-not-to-use (when key is known, need quality gate status), with specific sibling tool alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch measures for a single project.
Wraps /api/measures/component. Returns both the raw list
(measures) and a dict keyed by metric name (measures_by_metric)
— handy when the agent wants to look up a single value quickly.
To find valid metric keys, call with the default set first — SonarQube ignores unknown metric keys and returns what it knows.
Examples:
- Use when: "What's the code coverage of einvy:aut_einvy?"
→ project_key='einvy:aut_einvy', default metric_keys.
- Use when: "Coverage on the feature/new-auth branch?"
→ add branch='feature/new-auth'.
- Use when: "Metrics on PR #42?" → pull_request='42'.
- Don't use when: You want to compare many projects — use
sonarqube_worst_metrics which bulk-fetches and ranks.
- Don't use when: You want the Quality Gate's per-condition
breakdown — that's sonarqube_quality_gate_status.
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | Yes | SonarQube project key (e.g. 'einvy:aut_einvy'). | |
| metric_keys | No | Metric keys to fetch (e.g. ['bugs', 'coverage', 'sqale_rating']). If omitted, a sensible default set is used: bugs, code_smells, coverage, vulnerabilities, ratings, ncloc, tests, alert_status. | |
| branch | No | Branch name to query (e.g. 'feature/xyz'). If omitted, the project's main branch is used. Mutually exclusive with pull_request. | |
| pull_request | No | Pull request identifier (e.g. '42'). If set, fetches measures from the PR decoration analysis. Mutually exclusive with branch. |
| Name | Required | Description |
|---|---|---|
| project_key | Yes | |
| project_name | Yes | |
| qualifier | Yes | |
| measures_count | Yes | |
| measures | Yes | |
| measures_by_metric | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds value by detailing return format (raw list and dict) and behavior on unknown metric keys. Some redundancy with schema mutual exclusion info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, wrapper, return format, advice, examples. Front-loaded and efficient, though slightly verbose with redundant listing of default metrics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, output schema, and 100% schema coverage, the description completes the picture by covering purpose, usage, behavior, and examples. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. The description adds minor context (default metric set) already present in schema. Does not significantly enhance parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool fetches measures for a single project, wraps SonarQube API, and distinguishes from siblings by specifying single project scope. Examples further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and when-not-to-use with specific sibling tool names (sonarqube_worst_metrics, sonarqube_quality_gate_status). Also advises on metric key discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the Quality Gate status for a project.
Wraps /api/qualitygates/project_status. Returns the overall status
(OK / WARN / ERROR / NONE) plus a per-condition
breakdown — exactly what's needed for "why is my QG failing?" or
"is PR #42 passing the gate?" queries.
NONE means the project exists but has no Quality Gate attached or
no analysis yet.
Examples:
- Use when: "Is einvy:aut_einvy passing its Quality Gate?"
→ project_key='einvy:aut_einvy'.
- Use when: "Which conditions fail on PR #42?"
→ project_key=..., pull_request='42'.
- Use when: "Does feature/xyz still pass the gate?"
→ add branch='feature/xyz'.
- Don't use when: You want raw metric values without
the pass/fail verdict — sonarqube_project_metrics is leaner.
- Don't use when: You want the list of failing projects
org-wide — use sonarqube_worst_metrics with
metric='alert_status' or aggregate manually.
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | Yes | SonarQube project key. | |
| branch | No | Branch name to check (e.g. 'feature/xyz'). If omitted, the main branch's gate status is returned. Mutually exclusive with pull_request. | |
| pull_request | No | Pull request identifier (e.g. '42'). Returns the PR's gate status from the decoration analysis. Mutually exclusive with branch. |
| Name | Required | Description |
|---|---|---|
| project_key | Yes | |
| status | Yes | |
| passed | Yes | |
| conditions_count | Yes | |
| failing_conditions | Yes | |
| conditions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, etc. The description adds operational context: wraps /api/qualitygates/project_status, returns per-condition breakdown, explains NONE meaning, and notes mutual exclusivity constraints. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, followed by bullet-point examples and 'Don't use' sections. It is slightly long but every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated 'Has output schema: true'), the description focuses on input parameters and purpose. It explains status values, use cases, and edge case (NONE). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds usage context through examples showing how to use project_key, branch, and pull_request, and clarifies mutual exclusivity. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Fetch the Quality Gate status for a project,' using a specific verb and resource. It clearly distinguishes from sibling tools by noting alternatives like sonarqube_project_metrics for raw metrics and sonarqube_worst_metrics for org-wide failures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use examples ('Use when: Is project passing?') and when-not-to-use alternatives ('Don't use when: want raw metric values'). It also explains mutual exclusivity of branch and pull_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank projects by the worst value of a single metric.
Algorithm:
Pull up to candidate_pool projects (optionally filtered by query).
Bulk-fetch metric for all of them in one /api/measures/search call.
Sort descending or ascending depending on whether higher is worse (e.g. bugs → descending, coverage → ascending).
Return the top limit.
For fine-grained metrics (bugs, vulnerabilities, code_smells,
ratings, duplicated_lines_density, open_issues) higher is worse.
For coverage, tests, line_coverage, branch_coverage —
lower is worse.
Examples:
- Use when: "Top 10 worst-coverage services across the org"
→ metric='coverage', limit=10.
- Use when: "Which einvy:* projects have the most bugs?"
→ metric='bugs', query='einvy', limit=5.
- Use when: "What projects have the worst security rating?"
→ metric='security_rating'.
- Don't use when: You only care about one project — use
sonarqube_project_metrics (one API call instead of two).
- Don't use when: You want branch-specific ranking — SonarQube's
/api/measures/search endpoint doesn't accept branch, so
this tool always ranks main-branch values.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Metric key to rank by. Common picks: 'bugs', 'vulnerabilities', 'code_smells', 'coverage', 'duplicated_lines_density', 'sqale_rating', 'reliability_rating', 'security_rating'. | |
| limit | No | Top-N projects to return after ranking. | |
| query | No | Optional substring to pre-filter projects by key or name before ranking. Highly recommended on large SonarQube instances. | |
| candidate_pool | No | How many projects to pull before ranking. Larger pool = more accurate ranking, slower response. Start at 100 and bump up if needed. |
| Name | Required | Description |
|---|---|---|
| metric | Yes | |
| direction | Yes | |
| limit | Yes | |
| candidates_scanned | Yes | |
| ranked_count | Yes | |
| query | Yes | |
| ranked | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotations, description details algorithm steps, API call pattern, metric directionality, and performance implications of candidate_pool parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with algorithm steps and examples, though slightly verbose; all content is relevant and front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: algorithm, parameters, performance, limitations, and distinguished from siblings; output schema exists, reducing need for return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds substantial meaning beyond 100% schema coverage by explaining how candidate_pool affects accuracy/speed, metric directionality, and query filtering purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ranks projects by the worst value of a single metric, with specific examples and differentiation from sibling tool for single-project queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not-to-use examples are provided, including alternative tool for single-project queries and branch-specific limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0sonarqube_get_issuessonarqube_list_projectssonarqube_project_metricssonarqube_quality_gate_statussonarqube_worst_metricsScored across 5 tools
Each tool targets a distinct SonarQube operation: listing projects, searching issues, fetching single-project metrics, checking quality gate status, and ranking projects by a metric. No overlap in purpose.
All tools have a 'sonarqube_' prefix, but the suffix pattern is inconsistent: 'get_issues' and 'list_projects' follow verb_noun, while 'project_metrics', 'quality_gate_status', and 'worst_metrics' use noun-based names. This mixed convention may cause confusion.
With 5 tools, the server is well-scoped for SonarQube interaction. Each tool earns its place without redundancy or clutter.
The set covers essential read operations (projects, issues, metrics, quality gate, ranking). Minor gaps exist, such as no tool for listing all metric keys or performing write operations, but these are reasonable omissions for a focused MCP server.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
