[nquinquenel]

MCP-714 https://sonarsource.atlassian.net/browse/MCP-714

Human description

HTTP tool discovery now uses the MCP SDK native filter. Request toolsets, read-only settings, OAuth scopes and tool enablement continue to narrow server permissions. Direct calls retain their authorization checks and OAuth challenges. Organization-specific schemas remain supported.

Agent description

The SDK 2.1.0 dependency is already present. The filter uses request transport context and the server-enabled tool registry. The response wrapper adjusts organization schemas while preserving SDK cursors, metadata and errors. Unsupported-method handling and stdio behavior stay unchanged. No performance gain is assumed.

Acceptance coverage: regression tests use a real SDK delegate for discovery, cover concurrent request isolation and hidden-tool call rejection, and retain OAuth, schema and direct-call coverage.

Vortex: repository project SonarSource_sonarqube-mcp-server is bound and both entitlements are enabled. Java guidance covered authentication, concurrency, tests and API design. The implementation keeps request state local and call authorization independent of discovery. DEEP analysis fixed one record-pattern finding. One finding remains on an untouched line: src/main/java/org/sonarsource/sonarqube/mcp/SonarQubeMcpServer.java:220, java:S106, “Replace this use of System.out by a logger.” Changed-file secrets scan passed. Dependency analysis reported eight existing LOW risks; dependencies did not change.

Independent review: clean, round 1, gpt-6.1-sol, zero blocking findings.

Validation gaps: Docker integration tests could not run because the local Docker daemon is unavailable; CI must cover the HTTP, STDIO and proxy integration suites. The independent reviewer could not execute Gradle because its isolated environment lacked the cached distribution and cannot reach the download host. Host preparation was not validated because repository guidance supplies no preparation plan. Host unit tests and spotlessCheck passed.

Repository guidance: root AGENTS.md was read. There is no ADR directory; this bounded transport change needs no decision record. Attachments used: none. Rollback: revert the implementation commit. No migration is required.

Usage: 7634684 tokens; gpt-6.1-sol. Review usage: 698662 tokens, one session.

This PR is opened as a draft by autonomous Fabrik. It may become ready only after its mechanical gates pass. Human approval and merge are required.

---

_{🤖 Co-authored by Fabrik}

[hashicorp-vault-sonar-prod]

MCP-714

[gitar-bot]

Code Review ✅ Approved 🔴 High risk 1 closed / 1 findings

Moving OAuth- and request-restriction checks into SDK discovery filtering could expose restricted tool schemas if request context is misapplied; direct-call checks remain.

Switches HTTP tool discovery to the MCP SDK native filter, using request transport context and the server-enabled tool registry while preserving request toolsets, read-only settings, OAuth scopes, and organization-specific schemas. The previously raised concern about tool-list loss once PR #681 lands was resolved by confirming the current head uses a consistent enabledTools list, with the rebase note to retain this filter when #681 merges. No open findings remain.

✅ 1 closed

✅ Cross-PR: HTTP tool filter loses its tool list once #681 lands

📄 src/main/java/org/sonarsource/sonarqube/mcp/SonarQubeMcpServer.java:260-267 📄 src/main/java/org/sonarsource/sonarqube/mcp/transport/PerRequestToolFilteringHandler.java:130-139
Breaks when this PR and #681 both merge, in either order. The PR that merges second fails to compile, or its rebase builds the SDK tool filter from a list other than the one passed to .tools(...).

How

1. This PR registers .addToolFilter(PerRequestToolFilteringHandler.toolFilter(enabledTools)) at SonarQubeMcpServer.java:266. enabledTools comes from filterForEnabledTools(supportedTools) at line 260.
2. MCP-713 Declare tool availability and centralize registration #681 removes supportedTools and filterForEnabledTools. It rewrites start() so that getFilteringTransport(...) and .tools(...) both use the registeredTools field (SonarQubeMcpServer.java:253,257).
3. toolFilter looks up each listed definition by name and returns false when the name is missing (PerRequestToolFilteringHandler.java:133-135). If the filter's list does not match the registered list, tools/list hides registered tools while tools/call still runs them.

Fix

• This PR: After rebasing onto MCP-713 Declare tool availability and centralize registration #681, build the filter with toolFilter(registeredTools), using the same list passed to .tools(...) and getFilteringTransport(...).
• MCP-713 Declare tool availability and centralize registration #681: If it merges second, add .addToolFilter(PerRequestToolFilteringHandler.toolFilter(registeredTools)) to the HTTP builder in start().

Compared 1cea4d0 with #681 at 3b5b324

Verification Rules 2/2 met Knowledge ✅ 2 PRs 2 inspected

Functional validation No results

Rules 2 passed 2 not applicable

✅ Internal artifact registries
✅ Repository license compliance

Knowledge ✅ 2 expectations met

Architecture tools are Cloud-only and opt-in expectation met
Architecture tools remain Cloud-only expectation met

Broader impact PRs 2 inspected

Cross-PR 2 PRs inspected 0 open impacts

PR 681: MCP-713 Declare tool availability and centralize registration Inspected
PR 726: MCP-742 Stabilize tool input schema serialization Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
91.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud