MCP Servers

Connect any AI agent to your real build data — so it answers from Build Scans and trends, not guesswork.

A coding-agent chat answering why a build failed — tool calls to the Develocity MCP server, then a diagnosis naming the failed test, its exception, and a Build Scan link.

Feature overview

MCP Servers

Develocity MCP Servers are how AI agents reach your build data. They expose your Build Scans, test results, failure analysis, Policy Scan results, and organization-wide analytics through the Model Context Protocol (MCP) — the open standard that AI agents such as Claude and Codex already speak — so an agent can answer "why did this build fail?" or "which projects waste the most CI time?" from your own data. Any vendor can speak MCP. What an agent gets back is the difference — every task, test, dependency, and cache decision, captured at build time by Develocity's own instrumentation, a depth raw CI logs and hand-built API scripts can't reconstruct. The MCP servers are read-only and hand over the facts — the agent draws the conclusions — and run inside your own infrastructure, so build data never leaves your network.

Works great with

Develocity Agents

Connect once — every AI agent your team already uses can reach it

Connect AI agents such as Claude and Codex with a standard MCP configuration — no custom integration code per tool.
The MCP server ships with Develocity's domain expertise, so the agent knows how to get the best from your build data — without your team being build experts.
Agents on restricted networks still reach it — a Develocity Edge node proxies the connection, including hybrid and network-policy-controlled deployments.

A coding-agent chat listing the Develocity MCP tools discovered at session start, grouped by purpose.

Agents get the answer, not a wall of raw data to wade through

Overview first, drill down on demand — the agent pulls a build summary, then full detail only where it's needed, spending tokens on the answer, not the whole build.
Tools and responses are shaped for agent consumption — summarized, paginated, scoped to what the agent can take in — keeping its context window free for the task.
Failures come already grouped and typed — test failures, dependency issues, cache misses — so the agent reasons instead of parsing text.
Eight structured views of each build — tasks, tests, caching, dependencies, performance, and more — replace the raw log an agent would otherwise guess from.

A coding-agent chat retrieving a build summary, then drilling into only the failing detail, then a compact diagnosis.

Observability

Your agent reads the same build record you do

Point your agent at any Build Scan and ask why a build failed — it reads the failure, stack trace, and timings directly.
Compare two builds in one step — a built-in comparison query surfaces the input that changed between a passing run and a failing one.
Ask whether a failure is new or familiar — similar failures across builds are grouped into recurring patterns, so a known issue is recognized, not rediscovered.
Test results carry Develocity's flaky-test verdicts, so the agent tells an unreliable test from a real regression instead of guessing.

A coding-agent chat comparing two builds, naming the inputs that changed between the passing and failing run, with both Build Scan links.

Analytics

Ask a question across every build, get an answer back in plain language

Ask a cross-project question in plain words — which projects have the worst cache-miss rate this month? — and the agent queries Develocity Analytics.
The agent writes the query against your build history — so an answer no longer depends on knowing the schema or writing SQL by hand.
Its answers draw on the same definitions as the dashboards your team already uses, so the numbers line up with what you already trust.
Turn an open-ended reliability or cost question into a ranked, actionable list — without building a report manually.

A coding-agent chat that wrote SQL against Develocity Analytics and returned a ranked table of projects by cache-miss rate.

Read-only, governed by your own access keys, and inside your own network

Read-only by design — the servers expose data to ask about; no tool can change a build, a setting, or an access key.
An agent reaches only what its Develocity access key allows — the same permissions and data scope the key already carries, nothing more.
Runs as a separate service inside your own network or VPC, so build data stays within the boundary Security & Compliance already defines.
Every agent request is marked and metered — you can see which queries come from agents, separately from people using Develocity directly.