MCP Server Installation Manual

This guide describes how to enable the MCP server provided by Develocity for your deployment. For information on how to connect AI agents to the MCP server, see AI Agents. For information on how to configure authentication, including OAuth sign-in, see Authentication.

The MCP server provided by Develocity is an extension and may not be enabled for your installation. Contact Develocity support or your customer representative to enable it.

Develocity MCP Server

The Develocity MCP Server brings Develocity's full build context into any MCP-enabled AI agent.

Enabling the MCP Server

The Develocity MCP Server is part of the Develocity Kubernetes Helm Chart. To enable the MCP Server, add the following property to your Develocity values.yaml:

values.yaml

mcpServer:
  enabled: true

For more details on how to configure your Develocity installation, see the Kubernetes Helm Chart Configuration Guide.

Confirm That the MCP Server Is Running

You can inspect the status of the MCP Server Pods:

kubectl get pods -l app.kubernetes.io/component=mcp-server --namespace develocity

Output

NAME                         READY   STATUS    RESTARTS   AGE
mcp-server-67bfcd7f6-t8kkn   1/1     Running   0          2m40s

You can verify that the MCP Server runs properly and is accessible by sending a curl request:

curl -X POST https://develocity.example.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer <Develocity Access Key>" \ (1)
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-03-26",
      "capabilities": {},
      "clientInfo": {
        "name": "curl-client",
        "version": "1.0.0"
      }
    }
  }'

1	The Develocity MCP Server requires an access key with the `Access build data via the API and MCP` permission for every interaction, including the `initialize` request and listing the available tools.

Output

{
   "jsonrpc":"2.0",
   "id":1,
   "result":{
      "protocolVersion":"2025-03-26",
      "capabilities":{
         "tools":{
            "listChanged":false
         }
      },
      "serverInfo":{
         "name":"develocity-mcp-server",
         "version":"2026.3.0"
      },
      "instructions":"Allows querying data from the Develocity server https://develocity.example.com"
   }
}

Develocity Analytics Tools

The Develocity Analytics tools bring Develocity's Reporting and Visualization data into any MCP-enabled AI agent. You need Develocity 2025.4 or higher with Athena Data Export enabled, or Develocity Reporting Kit 2.1 or higher.

Enabling the MCP Server

The configuration steps depend on whether you are using Develocity Reporting and Visualization with Amazon Athena or using the Develocity Reporting Kit.

Develocity with Amazon Athena
Develocity Reporting Kit

Prerequisites

The Develocity Analytics tools require that the Athena Data Export feature is enabled. To enable it, follow the steps in the user manual.

The Develocity Analytics tools run as part of the Develocity MCP Server. Enable it and select the Athena analytics engine in your values.yaml:

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: athena

Set Up Read-Only Athena Credentials

For security reasons, the Athena credentials used by the MCP Server cannot be the same as the ones used by the Athena Data Export feature. The credentials used by the MCP Server must be read-only.

Create the Read-Only Athena Role

Create an IAM role in AWS with the permission to read build model data exported by Develocity. Use the following policy JSON as a template for setting up the permissions.

The resources in the policy JSON below are placeholders. Replace these with your actual AWS resource ARNs.

The policy includes permissions such as PutObject and DeleteObject. These permissions must apply only to the S3 bucket used by Athena for storing query results, not the bucket containing the actual build model data.

IAM Permission Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Read the build model data bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "exported-data-bucket:arn",
        "exported-data-bucket:arn/*"
      ]
    },
    {
      "Sid": "Put and get query result objects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket",
        "s3:ListBucketMultipartUploads",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload",
        "s3:PutObject"
      ],
      "Resource": [
        "workgroup-output-bucket:arn/output-location",
        "workgroup-output-bucket:arn/output-location/*"
      ]
    },
    {
      "Sid": "Create output location bucket if it doesn't exist",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:CreateBucket",
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": [
        "workgroup-output-bucket:arn",
        "workgroup-output-bucket:arn/*"
      ]
    },
    {
      "Sid": "Execute queries and get their results",
      "Effect": "Allow",
      "Action": [
        "athena:GetQueryExecution",
        "athena:GetQueryResults",
        "athena:GetQueryResultsStream",
        "athena:GetWorkGroup",
        "athena:StartQueryExecution",
        "athena:StopQueryExecution"
      ],
      "Resource": [
        "athena:workgroup:arn/workgroup-name"
      ]
    },
    {
      "Sid": "Read Glue metadata",
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetPartitions",
        "glue:GetPartition"
      ],
      "Resource": [
        "glue:catalog:arn",
        "glue:database:arn/database-name",
        "glue:table:arn/database-name/*"
      ]
    },
    {
      "Sid": "List databases",
      "Effect": "Allow",
      "Action": [
        "athena:ListDatabases"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Make the Read-Only Athena Role Available to Develocity

Once you have a read-only role ready to use, you can make it available to Develocity in one of two ways:

Create an AWS user, grant it the read-only role, and provide the user’s access key ID and secret access key to Develocity.
Use credentials provided by the AWS environment, such as IAM Roles for Service Accounts (IRSA) or an EC2 Instance Profile.

Access Key Credentials

Using access key credentials is straightforward, but requires you to manage the lifecycle of the credentials, including securing and rotating them.

IRSA or Instance Profile Credentials

To use credentials provided by the environment for the read-only Athena role, first consider if you are already using them elsewhere in Develocity (for example, for S3 object storage, IAM database authentication, or for the read/write access required by Athena Data Export).

A Kubernetes Pod in EKS can only have one attached IAM role, and an EC2 instance can only have one Instance Profile with one corresponding IAM role. To avoid reusing unnecessarily powerful credentials for Athena access, Develocity can assume a role specified with an ARN using its existing credentials.

For this to work, configure your read-only Athena role’s Trust Policy so that it can be assumed by the role currently used by Develocity (defined by your IRSA Kubernetes ServiceAccount annotation or your EC2 Instance Profile).

The following Trust Policy JSON allows the role to be assumed by a role called develocity-app. Replace this placeholder with the ARN of the role used by your Develocity installation.

Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<aws-account-id>:role/develocity-app"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Helm Configuration

Using Access Key Credentials

You can configure access key credentials either inline in your Helm values or using a user-managed Kubernetes Secret.

To configure them inline, set mcpServer.analytics.athena.credentials.keys.accessKey and mcpServer.analytics.athena.credentials.keys.secretKey.

To configure them in a user-managed Secret, provide the name of a Kubernetes Secret in the installation namespace. The Secret must have two data fields: accessKey and secretKey.

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: athena
    athena:
      credentials:
        type: keys
        keys:
          accessKey: <AWS access key for read-only Athena role>
          secretKey: <AWS secret key for read-only Athena role>
          # OR
          secretName: <Secret name with credentials for read-only Athena role>

mcpServer.analytics.athena is the canonical location for the Athena analytics source. The older athenaDataExport.mcpServer location still works but is deprecated; if you set it, the chart renders a deprecation warning. Move existing configuration to mcpServer.analytics.athena (and set mcpServer.analytics.type: athena).

Using an Assumed Role

To use Develocity’s existing IAM role to assume the read-only Athena role, configure Develocity with the ARN for the read-only role. Develocity uses its existing IRSA or Instance Profile credentials to assume this role. For this to work, you must have configured the read-only role to be assumable by Develocity’s existing role, as described in IRSA or Instance Profile Credentials.

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: athena
    athena:
      credentials:
        readOnlyRoleArn: arn:aws:iam:...

Prerequisites

Serving the Develocity Analytics tools from the Develocity /mcp endpoint against a connected Reporting Kit requires Develocity 2026.3 or higher and Develocity Reporting Kit 2.4 or higher.

Starting with Develocity 2026.3, the Reporting Kit’s analytics run on the consolidated Develocity MCP Server rather than the embedded /drv-mcp endpoint on the Reporting Kit instance. The Develocity MCP Server reaches the Reporting Kit’s data over its Trino query-access endpoint, so the endpoint must be exposed and the Develocity cluster must be able to reach it. For the migration steps, see Changes.

Connectivity and Ingress

The Develocity MCP Server calls the Reporting Kit from the Develocity cluster, which is a new outbound direction: previously only the Reporting Kit reached Develocity. Before enabling this, confirm that:

The Develocity cluster allows outbound connectivity to the Reporting Kit, and any network policy for the mcp-server Pod permits it.
The Reporting Kit exposes its Trino query-access endpoint. This is off by default and is enabled on the Reporting Kit side. See Develocity MCP Server Access in the Reporting Kit installation manual.

The Develocity MCP Server connects over TLS. If the query-access endpoint’s certificate is not already trusted by the Develocity JVM, see TLS Trust below.

Enable the Reporting Kit Analytics Source

On the Develocity side, enable the MCP Server, select the Reporting Kit analytics engine, and point it at your Reporting Kit’s base URL by adding the following to your Develocity values.yaml:

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: reportingKit (1)
    reportingKit:
      url: https://reporting-kit.example.com (2)

1	Selects the Reporting Kit (Trino) analytics engine. Set `athena` instead to use Athena Data Export; the two engines are mutually exclusive, so you set exactly one `type`.
2	The Reporting Kit’s base URL — the same host that serves its web UI (its `ingress.hostname`).

An installation uses at most one analytics engine. mcpServer.analytics.type selects it (athena or reportingKit); configuring more than one is an error.

Authenticating to the Query-Access Endpoint

How the Develocity MCP Server authenticates to the Reporting Kit’s Trino query-access endpoint depends on your deployment topology. Configure the matching mode on both sides.

Same Kubernetes cluster (service account token)

When Develocity and the Reporting Kit run in the same cluster (in separate namespaces), the Develocity MCP Server presents its Kubernetes service account token, which the Reporting Kit validates. No secret is shared between the two deployments; they agree only on a trusted service account identity. This is the default mode: configure the trusted service account on the Reporting Kit side under auth.develocityMcpServer.serviceAccount, and no credential is needed.

Separate clusters (static credential)

When Develocity and the Reporting Kit run in separate clusters, the service account token cannot be validated across the cluster boundary, so the server authenticates with a static username and password over HTTP Basic. Provide the credentials on the Develocity side with a user-managed Secret, and set the same username and password independently on the Reporting Kit side.

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: reportingKit
    reportingKit:
      url: https://reporting-kit.example.com
      credentials:
        secretName: develocity-mcp-query-access-credentials (1)

1	A user-managed Kubernetes Secret in the installation namespace with two data items, `username` and `password`. The same values must be set on the Reporting Kit side.

For the Reporting Kit side of each mode, see Query Trino From Outside the Cluster in the Reporting Kit installation manual.

TLS Trust

When the Reporting Kit’s query-access endpoint presents a TLS certificate that the Develocity JVM already trusts — for example, one signed by a public or your organization’s internal Certificate Authority — no additional configuration is needed.

If the endpoint presents a self-signed or otherwise untrusted certificate, provide the signing CA (or a truststore) on the Develocity side with mcpServer.analytics.reportingKit.tls.truststore:

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: reportingKit
    reportingKit:
      url: https://reporting-kit.example.com
      tls:
        truststore:
          secretName: develocity-mcp-query-access-truststore (1)
          key: ca.crt (2)
          passwordKey: password (3)

1	A user-managed Kubernetes Secret holding the CA certificate (PEM) or truststore file used to verify the endpoint.
2	The key within the Secret that holds the certificate or truststore file. Defaults to `ca.crt`.
3	Optional. The key holding the truststore password — only for a JKS or PKCS12 truststore; omit for a PEM CA certificate.

Confirm That the MCP Server Is Running

You can verify that the Develocity Analytics tools are available by sending a curl request:

curl -X POST https://develocity.example.com/mcp \ (1)
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer <Develocity Access Key>" \ (2)
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-03-26",
      "capabilities": {},
      "clientInfo": {
        "name": "curl-client",
        "version": "1.0.0"
      }
    }
  }'

1	Use your Develocity instance URL for both analytics sources. Whether the source is Athena Data Export or a connected Reporting Kit, the Analytics tools are served from the Develocity `/mcp` endpoint.
2	The Develocity Analytics tools require a valid Access Key for every interaction, not just for tool calls.

Output

{
   "jsonrpc":"2.0",
   "id":1,
   "result":{
      "protocolVersion":"2025-03-26",
      "capabilities":{
         "tools":{
            "listChanged":false
         }
      },
      "serverInfo":{
         "name":"develocity-mcp-server",
         "version":"2026.3.0"
      },
      "instructions":"Allows querying data from the Develocity server https://develocity.example.com"
   }
}