用于 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
工具注解 — 所有五个工具都带有 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 — 单个项目的度量指标（默认集涵盖错误/覆盖率/异味/评级/ncloc/测试/警报状态）
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_worst_metrics 外，每个工具都对 SonarQube 进行一次 HTTP 调用，后者执行一次搜索调用 + ⌈候选池/100⌉ 次批量指标调用。默认设置下通常 ≤ 2 次调用。
在健康的 SonarQube 实例上，单工具响应时间通常 < 500 毫秒。
分页直接传递给 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.
