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)와 마크다운 요약을 반환하므로, 구조화된 콘텐츠 지원 여부와 관계없이 클라이언트가 응답을 사용할 수 있습니다.
구조화된 오류 — 401 / 403 / 404 / 400 / 429 / 5xx 오류가 실행 가능한 힌트(예: "토큰 재생성", "sonarqube_list_projects로 프로젝트 키 확인")와 함께 매핑됩니다.
Pydantic 입력 유효성 검사 — 모든 인수에 대해 적용되며, 요청이 전송되기 전에 심각도/유형 필터가 유효한 SonarQube 열거형과 대조되어 확인됩니다.
프로젝트 간 최악 지표 순위 매기기 — 내부적으로 /api/measures/search 호출을 일괄 처리하며, 선택한 지표에 따라 값이 높을수록 나쁜지 낮을수록 나쁜지에 맞춰 오름차순 또는 내림차순으로 정렬합니다.
검색
sonarqube_list_projects — 선택적 텍스트 필터를 포함한 페이지네이션 프로젝트 검색
단일 프로젝트 통찰
sonarqube_project_metrics — 단일 프로젝트에 대한 측정값(기본 세트: 버그 / 커버리지 / 코드 스멜 / 등급 / ncloc / 테스트 / alert_status)
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 (끝에 슬래시 제외) |
| 예 | Bearer 토큰. 생성 위치: 내 계정 → 보안 → 토큰 |
| 아니오 |
|
HTTP 프록시 관련 참고사항. 자체 호스팅된 SonarQube는 일반적으로 내부 네트워크에서만 접근 가능하기 때문에, 클라이언트는 의도적으로 환경 기반 프록시 검색(trust_env=False)을 비활성화합니다. 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 호출을 수행합니다. sonarqube_worst_metrics는 하나의 검색 호출 + ⌈후보군/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.
