Skip to main content
Glama

sonarqube_worst_metrics

Read-onlyIdempotent

Rank projects by the worst value of a single metric, like bugs or coverage, to identify which need attention most.

Instructions

Rank projects by the worst value of a single metric.

Algorithm:

  1. Pull up to candidate_pool projects (optionally filtered by query).

  2. Bulk-fetch metric for all of them in one /api/measures/search call.

  3. Sort descending or ascending depending on whether higher is worse (e.g. bugs → descending, coverage → ascending).

  4. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metricYesMetric key to rank by. Common picks: 'bugs', 'vulnerabilities', 'code_smells', 'coverage', 'duplicated_lines_density', 'sqale_rating', 'reliability_rating', 'security_rating'.
limitNoTop-N projects to return after ranking.
queryNoOptional substring to pre-filter projects by key or name before ranking. Highly recommended on large SonarQube instances.
candidate_poolNoHow many projects to pull before ranking. Larger pool = more accurate ranking, slower response. Start at 100 and bump up if needed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metricYes
directionYes
limitYes
candidates_scannedYes
ranked_countYes
queryYes
rankedYes
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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