Most build questions arrive the same way: someone sends a link to a red build and asks what broke. Answering it by hand means opening the build, scrolling a log that can run to tens of thousands of lines, checking which tests failed and whether they were already muted, and looking at what changed since the last green run.
With the read-only MCP server for TeamCity, released as 1.0.0 on November 2, I paste the user's message, link included, into the agent and get a root-cause analysis back. It's built from the real log lines, failed tests and commits, so I can check every claim in it against the build. Nobody downloads a log.
The server has 29 tools across projects, build configurations, builds, logs, tests, agents and the queue. None of them can trigger, cancel, pin or tag anything. It's the second server in this series after Akamai; why I only build read-only ones is a separate post.
From a link to a root cause
The slow part of a failed build is rarely the fix. It's finding the line that explains it. The error can sit thousands of lines into the log, while the end of the log shows artifact publishing and cleanup. Then you still have to check whether the failing test was already broken last week, and which commit went in.
With the server, the agent does that legwork. You paste the link as the user sent it, and the answer comes back with the error lines from the log, the tests that failed (new failures first, already-muted ones marked), and the commits that went into the build.
- Find the build from the link.
- Read its error lines, failed tests and build problems.
- List the commits in the build.
- Write the root cause, quoting log lines, tests and commits.
Links to builds, pipelines, projects and commits all work, whether they come from the browser, a chat message or an old bookmark. The first step is one call that pulls everything TeamCity knows about the failure, and it's small enough to leave room for the conversation. If the agent needs more, it can read the log around a specific line or check who is already investigating a test.
For the person who sent the link, the answer arrives with the failing line, the test and the commit that probably caused it, and every one of them can be checked in TeamCity.
"Where's the pipeline for X?"
Not every question comes with a link. Someone asks where the production deploy for the payments service is, or which pipeline builds the docs site. They don't know the configuration's name, let alone its ID, and TeamCity's search wants one or the other.
The agent can work from that description. It finds configurations by approximate names and project paths, so "prod deploy for payments" lands on the right pipeline. When two candidates fit about equally well, say the production and staging deploys, it shows both and asks which one was meant instead of picking one.
Giving an agent access to CI
A CI server can deploy to production, so handing an agent a token to it is a fair thing to worry about. This server only reads: it can't trigger, cancel, pin or tag builds, and a test fails if its HTTP client ever gets a method other than GET.
Keep the token read-only as well. In TeamCity, create it with Limit per project and the Read-only preset. That preset covers everything the tools read and nothing that changes a build.
What the agent can answer
- "Why did this build fail?" with a pasted link
- "Find the deploy pipeline for the auth service."
- "Show me the last 10 builds of the API build and which ones failed."
- "Which agents are offline right now?"
- "What's in the build queue and why is it waiting?"
- "Who is investigating the failures in the Payments project?"
Setup
claude mcp add teamcity \ -e TEAMCITY_BASE_URL=https://teamcity.example.com \ -e TEAMCITY_TOKEN=your-token \ -- uvx readonly-mcp-teamcity Python 3.11 or newer, or the container from GHCR. Source, the full tool list and a comparison with JetBrains' own MCP server and the community ones: readonly-mcp-teamcity on GitHub.
One question it still doesn't answer well is "when did this start?" That means going through the logs of many past builds, and I haven't built that part yet.
