Your CI Server Just Became an Agent Tool: What TeamCity's MCP Server Means for Deploy-From-Chat

The build is red, and your agent already knows why — it read the log, found the failing test, checked whether an agent was even free to run the retry, and is now asking if it should re-run the build or roll the deploy back. No dashboard was opened. No one pasted a stack trace into chat. That is what happens when a CI server stops being a website and starts being a tool: Daghis/teamcity-mcp, a community Model Context Protocol server for JetBrains TeamCity, exposes builds, tests, agents, VCS roots, and configuration to Claude Code, Cursor, and Windsurf as callable tools. And in June 2026 the idea graduated from community experiment to vendor strategy, when JetBrains shipped first-party AI integration — a built-in MCP endpoint and a CLI with an installable agent skill — in TeamCity 2026.1.

Here is the shape of the answer up front — the two modes, what each one hands an agent, and where the official tooling fits:

Two details make the table more interesting than a feature list. First, version 2.0.0 moved 15 tools — queue management, agent compatibility checks, server health monitoring — from Dev to Full, an explicit admission that even reading operational state deserves a higher trust tier than reading build logs. Second, JetBrains' official path (the <server-url>/app/mcp endpoint plus the TeamCity CLI's agent skill for Claude Code, Codex, and Junie) covers the common workflows — reading logs, diagnosing failures, rerunning builds — while the community server's remaining edge is breadth of write operations. The community maintainer said so directly: the project is stable and in low-key maintenance as of June 2026, and the official tooling is the better default for most workflows. That frames this post: not which server to install, but what CI-as-agent-tools changes about the deploy pipeline — and which end of the tool list needs a lock on it.

The CI half of deploy-from-chat, as an actual tool sequence​

Deploy-from-chat demos usually start at the deploy step: an agent calls a PaaS API and a container rolls out. The unglamorous half is everything before it — the build that produced the image, the test run that gated it, the agent capacity that scheduled it. A TeamCity MCP server turns that half into a tool sequence an agent can walk without human transcription:

1. Trigger. trigger_build takes a buildTypeId, an optional branch, and a comment. The agent that decided a deploy is needed can kick off the exact upstream build itself instead of asking a human to click through to the right configuration.
2. Wait. wait_for_build polls until the build reaches a terminal state — finished, failed, or canceled — with a configurable timeout (default 600 seconds, up to 3,600) and poll interval. This is the tool that closes the async gap: the agent blocks on CI the way a pipeline stage does, then continues the conversation with the result.
3. Diagnose. get_build_results returns tests, artifacts, statistics, changes, and dependencies in one call; fetch_build_log pages or tails the log with server-side filtering (locator, fields) so the agent pulls the failing lines instead of a megabyte of stdout. "Why is the build red?" becomes two tool calls with evidence attached.
4. Check capacity. Queue totals, queue wait reasons, and the agent pool answer the question every retry needs first: is a runner even free? Version 2.0.0 deliberately put these behind Full Mode — capacity state is operational state, and the maintainers treat it accordingly.
5. Hand off with provenance. The agent now holds the build ID, the test verdict, the artifact set, and the capacity picture. When it triggers the deploy, it can cite all four — the CI-to-deploy loop closes without a dashboard, and the deploy decision carries its own audit trail.

Nothing in that sequence requires Full Mode except step 4 — that is the point of the two-tier design. The everyday loop — trigger, wait, read, decide — runs on 31 tools and ~14k tokens of context. Full Mode exists for the day the agent needs to change what CI is, not just what it ran. That day is rarer, more dangerous, and exactly where the next two sections live.

TeamCity is not alone here. The broader CI/CD MCP landscape filled in fast: the official GitHub MCP server is the most widely deployed DevOps MCP server in production, CloudBees ships a Unify MCP server spanning Jenkins, GitHub Actions, and CloudBees Workflows, and curated catalogs added MCP servers for Azure DevOps, GitLab, JFrog, Jenkins, Argo CD, and Pulumi in a single quarter. CI-as-agent-tools is no longer one project's experiment; it is the direction the whole category is walking.

What Full Mode adds beyond build status​

Full Mode's 87 tools read like a TeamCity administrator's click-path turned into an API surface. Grouped by blast radius, from "annoying" to "career-limiting":

• Build configuration authoring. Create and clone build configurations; manage build steps, triggers, and dependencies. A misconfigured trigger doesn't just fail — it can fire builds in a loop and burn through agent hours while everyone sleeps.
• Queue management. Cancel queued builds, reorder the queue. On a shared fleet, one agent's "cancel the stale stuff" is another team's builds evaporating.
• Agent management. Configure build agents and check compatibility. Disabling the wrong agent — or marking agents incompatible with a widely used configuration — stalls the fleet silently; nothing fails, nothing runs.
• VCS roots. Configure the version-control roots builds check out from. Repointing a root changes what code gets built, which makes it one of the quietest ways to compromise every downstream artifact.
• Project and parameter CRUD. Create, update, and delete whole projects; full create/read/update/delete on build-config, project, and output parameters. Parameters are secrets-adjacent by nature — credentials, signing keys, deployment targets flow through them — and delete_project needs no further elaboration.
• Server administration and health. Server-level settings and health monitoring: the controls that decide whether the CI server itself stays standing.

The honest summary: Full Mode hands an agent the keys to the CI kingdom, and the token model underneath is a single TEAMCITY_TOKEN with whatever permissions that token carries. The server redacts sensitive values in logs, which is good hygiene, but redaction is not authorization. Every tool in the list above executes with the token's full authority. That is precisely why the mode split exists — and why a mode split alone is not enough.

The scoping rule: not every tool deserves the same key​

MCP_MODE=dev|full is a coarse gate: one environment variable decides whether the agent sees 31 tools or 87. Version 2.1.0 added runtime switching (get_mcp_mode/set_mcp_mode, no restart required), so a session can escalate from Dev to Full and back — better, but still all-or-nothing within each tier. An agent doing routine triage in Dev Mode can trigger and cancel builds freely; an agent granted Full Mode for one queue check can also delete a project. The mode boundary is drawn in the right place, but the tools inside each mode still span wildly different blast radii.

The fix is per-tool scoping with human approval on the dangerous end — a pattern the MCP ecosystem already converged on:

The machinery for the middle and bottom rows already exists outside this one server. Scoped MCP proxies wrap any server with per-agent credential isolation and an operator approval flow — the agent's call is rejected with an approval ID, the operator runs something like scoped-mcp hitl approve <id>, and the call proceeds. Governed MCP gateways push every mutation into a human-approval queue by default, with no code path that mutates infrastructure without a grant. Production gateway patterns add async approval queues, OAuth token injection so raw credentials never reach the agent, and audit logging on every call. The consistent lesson across all of them: access models built for human users — one token, one trust level — break down when the requester is an agent making dozens of calls a minute, and least privilege has to be provable (scoped tools, passthrough identity, audit logs) rather than assumed.

Applied to a TeamCity MCP server, the rule writes itself. Run Dev Mode on a view-plus-trigger token for everyday triage. Escalate to Full Mode only inside an approval-gated session, with project deletion, VCS root edits, and server admin either denied outright or bound to a credential the agent never holds. CI infrastructure settings are exactly the tools that need per-tool auth and a human in the loop before an agent touches them — they decide what code gets built, where it runs, and whether the evidence trail survives.

What this closes for a self-hosted PaaS​

Step back and the shape is simple. Deploy-from-chat has always had two halves: the PaaS half (roll the container out, tail the logs, roll back) and the CI half (what was built, what gated it, what capacity ran it). The PaaS half got its MCP servers first — Coolify bridges, managed tool runtimes, gateway-exposed REST APIs. TeamCity's MCP story, community and now official, fills in the other half: the same agent that triggers a deploy can read the build that produced the image, the test run that gated it, and the agent-pool capacity behind it, then cite all three when it acts.

For a self-hosted PaaS, that closure matters twice. First, provenance: a deploy decision that carries its build ID, test verdict, and artifact set is auditable in a way "the agent said so" never will be — and on machines you own, the audit trail is your compliance story. Second, cost: every dashboard click an agent replaces is latency out of the loop, but every unscoped infrastructure tool is blast radius into it. The teams that get this right will run narrow tools with approval gates, not one token with eighty-seven powers.

The trajectory is clear enough to bet on. JetBrains blessing a built-in MCP endpoint and CLI agent skills means CI vendors now treat agent-addressability as product surface, not plugin territory. Expect the write side to grow — more configuration tools, more queue and agent control, eventually pipeline authoring — and expect the scoping side to grow with it, because the first agent that deletes a project it was only asked to "clean up" will teach the lesson to everyone at once. Build the approval gates before that story has your team's name in it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.