---
component: reporting-kit
version: "2.4"
slug: reporting-kit/develocity-mcp-server
canonical_url: "https://docs.develocity.ai/reporting-kit/2.4/develocity-mcp-server/"
title: "Develocity MCP Server Access"
description: "Configure a Develocity Reporting Kit so the Develocity MCP Server can serve its Analytics tools over the Reporting Kit's Trino query-access endpoint."
keywords: []
status: current
---

<!-- llms-index: https://docs.develocity.ai/llms.txt -->

# Develocity MCP Server Access

<a id="preamble"></a>

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](https://docs.develocity.ai/reporting-kit/2.4/#embedded_analytics_mcp_deprecation)).

To allow it, enable [Trino query access](https://docs.develocity.ai/reporting-kit/2.4/#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`.

<a id="same-cluster-service-account-token"></a>

## 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](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles) so it can validate presented tokens against the Kubernetes API; no additional configuration is required.

> [!TIP]
> 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.

<a id="separate-clusters-static-credential"></a>

## 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](https://docs.develocity.ai/reporting-kit/2.4/#user-managed-secrets) 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.