SonarQube 用のMCPサーバーです。LLMエージェント（Claude Code、Cursor、OpenCodeなど）がプロジェクトの発見、主要メトリクスの取得、品質ゲートステータスの確認、重大度やタイプによるフィルターを用いた課題の検索、および特定のメトリクスが「最も悪い」プロジェクトのランキング作成を行えるようにします。
Python、FastMCP、stdioトランスポートを使用しています。
SonarQube 9.x / 10.xインスタンス（セルフホスト）およびSonarCloudで動作します。
既存のSonarQube MCPはいくつか存在しますが、単一プロジェクトの読み取りにとどまる傾向があります。本サーバーはプロジェクト横断的なランキング機能（sonarqube_worst_metrics）を追加しました。これは、リードエンジニアがトリアージセッションで実際に行う「組織内でカバレッジが最も低いサービス上位10件を表示して」といった操作を可能にします。すべてのツールは読み取り専用であり、安全にパラメータ化されています（Pydanticによる入力検証、重大度/タイプのホワイトリスト）。
Related MCP server: sonarqube-api-mcp
ツールアノテーション — 5つのツールすべてに readOnlyHint: True、destructiveHint: False、idempotentHint: True が設定されています。このサーバーからSonarQubeを変更することはできません。
構造化された出力 — すべてのツールは型付きペイロード（TypedDict）とMarkdown形式の要約を返すため、構造化コンテンツのサポートの有無にかかわらず、クライアントは有用なレスポンスを得られます。
構造化されたエラー — 401 / 403 / 404 / 400 / 429 / 5xx エラーは、実行可能なヒント（例：「トークンを再生成してください」、「sonarqube_list_projectsでプロジェクトキーを確認してください」など）にマッピングされます。
Pydanticによる入力検証 — すべての引数に対して検証が行われます。重大度やタイプのフィルターは、リクエスト送信前に有効なSonarQubeの列挙型と照合されます。
プロジェクト横断的なワーストメトリクスランキング — 内部で /api/measures/search 呼び出しをバッチ処理し、選択したメトリクスに応じて昇順または降順でソートします。
発見
sonarqube_list_projects — テキストフィルター（オプション）付きのページネーション可能なプロジェクト検索
単一プロジェクトの洞察
sonarqube_project_metrics — 1つのプロジェクトのメトリクス（デフォルトセットにはバグ / カバレッジ / コードの不吉な臭い / レーティング / 行数 / テスト / アラートステータスが含まれます）
sonarqube_quality_gate_status — 品質ゲートのステータスと条件ごとの失敗内容
課題のトリアージ
sonarqube_get_issues — 重大度 / タイプ / 解決ステータスでフィルタリングされた課題検索
プロジェクト横断的なランキング
sonarqube_worst_metrics — メトリクスの値が最も悪い順にソートされた上位N件のプロジェクト（例：カバレッジが最も低い、バグが最も多いなど）
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-mcpまたは .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"
}
}
}
}確認：
claude mcp list
# sonarqube: uvx --from sonarqube-mcp sonarqube-mcp - ✓ Connected変数 | 必須 | 説明 |
| はい | SonarQubeのURL（末尾のスラッシュは不要） |
| はい | ベアラートークン。生成場所：マイアカウント → セキュリティ → トークン |
| いいえ |
|
HTTPプロキシに関する注意：クライアントは意図的に環境変数ベースのプロキシ検出（trust_env=False）を無効にしています。これは、セルフホストのSonarQubeは通常、内部ネットワークからのみ到達可能であるためです。SonarCloudや企業プロキシの背後にあるSonarQubeに接続する場合は、現時点ではプロセスレベルでプロキシ変数を解除する必要があります。SONARQUBE_TRUST_ENV_PROXY オプションは次回のリリースで対応予定です。
「'einvy'に一致するすべてのSonarQubeプロジェクトをリストアップして」
「einvy:aut_einvy の品質ゲートステータスはどうなっていますか？」
「バグが最も多いプロジェクト上位10件を表示して」
「einvy:aut_einvy 内のすべての BLOCKER / CRITICAL な脆弱性を探して」
「einvy:qa_assistant のカバレッジは？」
「クエリ 'einvy' に一致するカバレッジが最も低いプロジェクト上位5件」
sonarqube_worst_metrics で使用）高いほど悪い（降順でソート — 数値が大きいほど悪い）：
bugs, code_smells, vulnerabilities, duplicated_lines_density, reliability_rating, security_rating, security_review_rating, sqale_rating, open_issues
低いほど悪い（昇順でソート — 数値が小さいほど悪い）：
coverage, line_coverage, branch_coverage, test_success_density, tests
SonarQubeのレーティングは、"1"（A、最高）から "5"（E、最低）までの数値文字列です。
すべてのツールは readOnlyHint: True であり、SonarQubeを変更することはできません。
POST / PUT / DELETE は一切呼び出されません。
重大度 / タイプ / 修飾子の入力は、API呼び出し前にSonarQubeの列挙型と照合されるため、誤字脱字があった場合はAPIを叩く前に即座に失敗します。
すべてのツールはSonarQubeに対して 1回のHTTP呼び出し を行います。ただし sonarqube_worst_metrics は例外で、1回の検索呼び出し + ⌈候補数/100⌉ 回のバルクメトリクス呼び出し を行います。デフォルト設定では2回以下の呼び出しで完了します。
正常なSonarQubeインスタンスにおける単一ツールの応答時間は、通常500ms未満です。
ページネーションはSonarQubeにそのまま渡されます（p および ps パラメータ）。MCPサーバー側で全結果をバッファリングすることはありません。
sonarqube_worst_metrics は candidate_pool を500に制限しています。数千のプロジェクトがあるインスタンスでは、ランキング前に query= でフィルタリングしてください（ツールのドキュメント文字列を参照）。
SonarQubeには公開された厳格なレート制限はありません。429エラーを受け取った場合、サーバーは実行可能なエラーを表示します（「30〜60秒待ってから再試行してください。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.
