Develocity MCP Server Access
Starting with Develocity 2026.3, the Develocity MCP Server serves the Reporting Kit’s Develocity Analytics tools. It queries 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 set it up:
-
Enable Trino query access on the Reporting Kit. You need TLS and a hostname on its Ingress, but not the Trino user account credentials: the Develocity MCP Server authenticates through
auth.develocityMcpServerinstead. -
Choose an authentication mode for your topology and configure it on both sides:
-
Same cluster: Develocity and the Reporting Kit run in one Kubernetes cluster, in separate namespaces.
-
Separate clusters: Develocity and the Reporting Kit run in different clusters.
-
Until you configure a mode under auth.develocityMcpServer, the Reporting Kit rejects queries from the Develocity MCP Server.
Configure exactly one mode.
If the Reporting Kit’s Ingress uses a self-signed or otherwise untrusted certificate, also give Develocity the signing CA. See TLS Trust.
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 name that the Reporting Kit accepts.
On the Reporting Kit, trust the Develocity MCP Server’s service account:
trino:
ingress:
enabled: true (1)
auth:
develocityMcpServer:
serviceAccount:
trustedServiceAccount: system:serviceaccount:develocity:mcp-server (2)
| 1 | Along with TLS and a hostname on the Reporting Kit’s Ingress; see Enabling Trino Query Access. The Trino user account isn’t needed for the Develocity MCP Server. |
| 2 | The Kubernetes service account of the Develocity MCP Server, in system:serviceaccount:<namespace>:<name> form. Adjust the namespace to match your Develocity installation. |
On Develocity, point the MCP Server at the Reporting Kit. No credential is needed:
mcpServer:
enabled: true
analytics:
type: reportingKit
reportingKit:
url: https://develocity-reporting-kit.example.com (1)
| 1 | The Reporting Kit’s base URL, its ingress.hostname. |
In this mode, the Helm chart grants the Reporting Kit’s trino-cache app the system:auth-delegator ClusterRole so it can validate presented tokens against the Kubernetes API.
|
|
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.
Create a user-managed secret with username and password data items in each cluster, with the same values in both, and keep the two copies in sync:
kubectl create secret generic develocity-mcp-query-access-credentials \
--namespace <namespace> \
--from-literal=username=develocity-mcp \
--from-literal=password=<password>
On the Reporting Kit, accept that credential:
trino:
ingress:
enabled: true (1)
auth:
develocityMcpServer:
staticCredentials:
secretName: develocity-mcp-query-access-credentials
| 1 | Along with TLS and a hostname on the Reporting Kit’s Ingress; see Enabling Trino Query Access. The Trino user account isn’t needed for the Develocity MCP Server. |
On Develocity, present it:
mcpServer:
enabled: true
analytics:
type: reportingKit
reportingKit:
url: https://develocity-reporting-kit.example.com (1)
credentials:
secretName: develocity-mcp-query-access-credentials
| 1 | The Reporting Kit’s base URL, its ingress.hostname. |