Provides read-only tools for interacting with SonarCloud, enabling discovery of projects, retrieval of quality metrics, Quality Gate status checks, issue search with filtering, and cross-project ranking by worst metric values.
Provides read-only tools for interacting with SonarQube instances, enabling discovery of projects, retrieval of quality metrics, Quality Gate status checks, issue search with filtering, and cross-project ranking by worst metric values.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sonarqube-mcp show me the top 5 worst-coverage projects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for SonarQube. Lets an LLM agent (Claude Code, Cursor, OpenCode, etc.) discover projects, pull headline metrics, check Quality Gate status, search issues with severity/type filters, and rank projects by the worst value of any metric.
Python, FastMCP, stdio transport.
Works with any SonarQube 9.x / 10.x instance (self-hosted) and with SonarCloud.
A few community SonarQube MCPs exist, but they tend to stop at single-project reads. This one adds cross-project ranking (sonarqube_worst_metrics) — the operation a lead actually runs during a triage session: "show me the top 10 worst-coverage services in the org". All tools are read-only and safely parameterised (Pydantic input validation, severity / type whitelists).
Related MCP server: sonarqube-api-mcp
Tool annotations — all five tools carry readOnlyHint: True, destructiveHint: False, idempotentHint: True. Nothing can mutate SonarQube from this server.
Structured output — every tool returns a typed payload (TypedDict) + a markdown summary, so clients with and without structured-content support both get a usable response.
Structured errors — 401 / 403 / 404 / 400 / 429 / 5xx mapped to actionable hints (e.g. "regenerate token", "check project key with sonarqube_list_projects").
Pydantic input validation for every argument; severity / type filters are checked against the valid SonarQube enum before the request is sent.
Cross-project worst-metric ranking — batches /api/measures/search calls under the hood, sorts ascending or descending based on whether higher is worse for the chosen metric.
Discovery
sonarqube_list_projects — paginated project search with optional text filter
Single-project insight
sonarqube_project_metrics — measures for one project (default set covers bugs / coverage / smells / ratings / ncloc / tests / alert_status)
sonarqube_quality_gate_status — Quality Gate status + per-condition failures
Issue triage
sonarqube_get_issues — issue search filtered by severity / type / resolution status
Cross-project ranking
sonarqube_worst_metrics — top-N projects sorted by the worst value of a metric (e.g. worst coverage, most bugs)
Requires 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-mcpOr 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"
}
}
}
}Check:
claude mcp list
# sonarqube: uvx --from sonarqube-mcp sonarqube-mcp - ✓ ConnectedVariable | Required | Description |
| yes | SonarQube URL (no trailing slash) |
| yes | Bearer token. Generate in: My Account → Security → Tokens |
| no |
|
Note on HTTP proxies. The client intentionally disables env-based proxy discovery (trust_env=False) because self-hosted SonarQube is typically reachable only on an internal network. If you connect to SonarCloud or any SonarQube that lives behind a corporate proxy, you'll currently need to drop the proxy variables at the process level — a SONARQUBE_TRUST_ENV_PROXY knob is planned for a follow-up release.
"List all SonarQube projects matching 'einvy'"
"What's the Quality Gate status for einvy:aut_einvy?"
"Show me the top 10 projects with the most bugs"
"Find all BLOCKER / CRITICAL vulnerabilities in einvy:aut_einvy"
"What's the coverage on einvy:qa_assistant?"
"Top 5 worst-coverage projects matching query 'einvy'"
sonarqube_worst_metrics)Higher is worse (sorted descending — more is worse):
bugs, code_smells, vulnerabilities, duplicated_lines_density, reliability_rating, security_rating, security_review_rating, sqale_rating, open_issues
Lower is worse (sorted ascending — less is worse):
coverage, line_coverage, branch_coverage, test_success_density, tests
Ratings in SonarQube are numeric strings "1" (A, best) through "5" (E, worst).
All tools are readOnlyHint: True — nothing can mutate SonarQube.
No POST / PUT / DELETE is ever called.
Severity / type / qualifier inputs are validated against SonarQube enums before the API call, so the tool fails fast on typos rather than hitting the API.
Every tool makes one HTTP call to SonarQube except sonarqube_worst_metrics, which makes one search call + ⌈candidate_pool/100⌉ bulk-measures calls. Default settings land at ≤ 2 calls.
Single-tool response time on a healthy SonarQube instance: typically < 500 ms.
Pagination is passed through to SonarQube (p + ps params) — no full-result buffering in the MCP server.
sonarqube_worst_metrics caps candidate_pool at 500 — on instances with thousands of projects, pre-filter with query= before ranking (see the tool docstring).
SonarQube has no published hard rate limit. If 429 is received the server surfaces an actionable error ("Wait 30-60 s before retrying; reduce 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mshegolev/sonarqube-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
