feat: support MCP tool calls

[Pasichniuk]

Applicable issues

• fixes MCP tools try out #165

Description of changes

Added new endpoint to call MCP server tools: POST /api/v1/deployments/mcp/{deploymentId}/call-tool

Checklist

• Title of the pull request follows Conventional Commits specification

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ai-dial-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 1 package(s) with unknown licenses.

See the Details below.

License Issues

settings.gradle

Package	Version	License	Issue Type
com.gradle:develocity-gradle-plugin	4.3.1	Null	Unknown License

OpenSSF Scorecard

Package	Version	Score	Details
maven/com.gradle:develocity-gradle-plugin	4.3.1	Unknown	Unknown

Scanned Files

• settings.gradle

[ai-dial-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 2 package(s) with unknown licenses.

See the Details below.

License Issues

settings.gradle

Package	Version	License	Issue Type
com.gradle:common-custom-user-data-gradle-plugin	2.1	Null	Unknown License
com.gradle:develocity-gradle-plugin	4.3.1	Null	Unknown License

OpenSSF Scorecard

Package	Version	Score	Details
maven/com.gradle:common-custom-user-data-gradle-plugin	2.1	Unknown	Unknown
maven/com.gradle:develocity-gradle-plugin	4.3.1	Unknown	Unknown

Scanned Files

• settings.gradle

[oleksii-donets]

Review: feat: support MCP tool calls

Overall the feature is clean and well-scoped. A few issues to address:

1. Code duplication — callTool duplicates the get() template pattern

McpService.callTool() manually repeats the same steps as the private get() method: get deployment → resolve endpoint → create client → initialize → call → catch. Consider extracting a shared execute helper that both get() and callTool() can use:

private <T> T execute(String deploymentId, Function<McpSyncClient, T> operation) {
    var deployment = getDeployment(deploymentId);
    var endpointPath = mcpEndpointPathResolver.resolveEndpointPath(deployment);
    try (var mcpClient = mcpClientFactory.create(deployment.getUrl(), endpointPath, deployment.getTransport())) {
        mcpClient.initialize();
        return operation.apply(mcpClient);
    } catch (Exception e) {
        // unified error handling
    }
}

Then callTool becomes a one-liner, and get() delegates to execute as well.

2. Potential NPE — ExceptionUtils.getRootCause(e) can return null

From the Apache Commons docs: getRootCause() returns null if the throwable has no cause chain (i.e., it is the root cause). This means ExceptionUtils.getRootCause(e).getMessage() will throw an NPE in that case.

Use ExceptionUtils.getRootCauseMessage(e) instead, or fall back:

var root = ExceptionUtils.getRootCause(e);
String reason = root != null ? root.getMessage() : e.getMessage();

3. @Transactional(readOnly = true) inconsistency

The new callTool method has @Transactional(readOnly = true), but the existing listing methods (getTools, getResources, getPrompts) don't. Either all MCP service methods that read deployments should have it, or none should. I'd suggest removing it from callTool to stay consistent with existing methods, unless there's a specific reason it was added.

4. Different error message style

The existing get() method uses a user-friendly message: "Failed to connect to MCP server. Make sure transport '...' and path '...' are correct." The new callTool uses a more technical message with root cause extraction. Consider keeping the error message style consistent — the user-friendly pattern from get() is preferable.

5. Test style inconsistency — JSON path constants

Existing tests in McpControllerTest inline the JSON resource paths directly in ResourceUtils.readResource() calls (e.g. ResourceUtils.readResource("/mcp/mcp_tools_response.json")). The new test extracts them into private static final constants (CALL_TOOL_REQUEST_DTO_JSON_PATH, CALL_TOOL_RESULT_DTO_JSON_PATH) even though each is used only once. Better to keep one style — inline them to match the existing pattern.

6. Minor — test JSON files missing trailing newline

Both call_tool_request_dto.json and call_tool_result_dto.json are missing a trailing newline (\ No newline at end of file).

[ai-dial-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 2 package(s) with unknown licenses.

See the Details below.

License Issues

settings.gradle

Package	Version	License	Issue Type
com.gradle:common-custom-user-data-gradle-plugin	2.1	Null	Unknown License
com.gradle:develocity-gradle-plugin	4.3.1	Null	Unknown License

OpenSSF Scorecard

Package	Version	Score	Details
maven/com.gradle:common-custom-user-data-gradle-plugin	2.1	Unknown	Unknown
maven/com.gradle:develocity-gradle-plugin	4.3.1	Unknown	Unknown

Scanned Files

• settings.gradle

[ai-dial-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 2 package(s) with unknown licenses.

See the Details below.

License Issues

settings.gradle

Package	Version	License	Issue Type
com.gradle:common-custom-user-data-gradle-plugin	2.1	Null	Unknown License
com.gradle:develocity-gradle-plugin	4.3.1	Null	Unknown License

OpenSSF Scorecard

Package	Version	Score	Details
maven/com.gradle:common-custom-user-data-gradle-plugin	2.1	Unknown	Unknown
maven/com.gradle:develocity-gradle-plugin	4.3.1	Unknown	Unknown

Scanned Files

• settings.gradle