Develocity MCP Server Access

Starting with Develocity 2026.3, the Develocity MCP Server serves the Reporting Kit’s Develocity Analytics tools by querying the Reporting Kit’s Trino query-access endpoint from the Develocity cluster. This replaces the embedded Analytics MCP endpoint that the Reporting Kit previously served (see Embedded Analytics MCP Endpoint Deprecated).

To allow it, enable Trino query access so the endpoint is reachable from the Develocity cluster, then configure how the Reporting Kit authenticates the Develocity MCP Server under auth.develocityMcpServer. Choose the mode that matches your deployment topology by setting exactly one of serviceAccount or staticCredentials. By default auth.develocityMcpServer is unset, and the Reporting Kit doesn’t accept queries from the Develocity MCP Server.

On the Develocity side, set mcpServer.analytics.reportingKit.url to the Reporting Kit’s base URL (the host that serves its web UI). When the ingress presents a certificate the Develocity JVM already trusts, no truststore configuration is needed on the Develocity side; if it presents a self-signed or otherwise untrusted certificate, you can provide the signing CA on the Develocity side via mcpServer.analytics.reportingKit.tls.truststore.

Same Cluster: Service Account Token

When Develocity and the Reporting Kit run in the same Kubernetes cluster, in separate namespaces, the Develocity MCP Server presents its Kubernetes service account token, and the Reporting Kit validates it against the cluster’s Kubernetes API. No secret is shared between the two deployments — they agree only on the service account identity (the account name the Reporting Kit accepts).

Set auth.develocityMcpServer.serviceAccount.trustedServiceAccount to the service account of the Develocity MCP Server, and auth.develocityMcpServer.serviceAccount.audience to the audience the presented token must carry.

values.yaml

auth:
  develocityMcpServer:
    serviceAccount:
      trustedServiceAccount: system:serviceaccount:develocity:mcp-server (1)
      audience: trino-query-access (2)

1	The Kubernetes service account of the Develocity MCP Server, in `system:serviceaccount:<namespace>:<name>` form. Adjust the namespace to match your Develocity installation.
2	The audience the presented token must carry. Use the same value the Develocity side is configured to request.

In this mode, the Reporting Kit’s trino-cache app is granted the system:auth-delegator ClusterRole so it can validate presented tokens against the Kubernetes API; no additional configuration is required.

system:auth-delegator is a cluster-scoped role, so installing in this mode binds a ClusterRole to the trino-cache service account. Make sure whoever installs the Reporting Kit has permission to create cluster-scoped RBAC (ClusterRoleBinding) resources — typically cluster administrator rights — or the installation fails.

Separate Clusters: Static Credential

When Develocity and the Reporting Kit run in separate clusters, a service account token can’t be validated across the cluster boundary. Instead, the Develocity MCP Server authenticates with a static username and password over HTTP Basic, protected by the query-access endpoint’s TLS.

Set auth.develocityMcpServer.staticCredentials.secretName to a user-managed secret containing username and password data items. You must set the same username and password on the Develocity side, in mcpServer.analytics.reportingKit.credentials, created independently in each cluster, and keep the two copies in sync.

values.yaml

auth:
  develocityMcpServer:
    staticCredentials:
      secretName: develocity-mcp-query-access-credentials (1)

1	A user-managed secret with two data items, `username` and `password`. The same values must be configured on the Develocity side.