TeamCity MCP Server
This MCP server exposes TeamCity CI/CD operations as typed tools so AI coding assistants can inspect, monitor, and manage TeamCity builds and configuration.
Test connectivity and switch between Dev and Full MCP modes at runtime.
Browse projects, build configurations, branches, parameters, and project hierarchy.
List and inspect builds, queued builds, build status/results, VCS changes, and server info.
Trigger builds and cancel queued or running builds; wait for builds to finish.
Fetch build logs with pagination/streaming and analyze test failures, problems, investigations, and muted tests.
List and download build artifacts in base64, text, or stream form.
In Full mode, create/clone/update build configurations, manage build steps/triggers/dependencies/VCS roots/agents, and perform parameter CRUD and queue/admin tasks.
Enables natural language control of JetBrains TeamCity CI/CD server, allowing users to trigger builds, monitor build status, fetch logs, analyze test failures, create build configurations, manage build steps and triggers, and configure VCS roots and agents.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@TeamCity MCP Server trigger a build for the main project and show me the status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
TeamCity MCP Server
A Model Control Protocol (MCP) server that bridges AI coding assistants with JetBrains TeamCity CI/CD server, exposing TeamCity operations as MCP tools.
Project status (October 2026): stable, low-key maintenance. This does what it set out to do and is no longer under active development. It still works and stays installable; issues and PRs may get slow or no response, and security fixes are best-effort.
JetBrains now ships official AI integration for TeamCity β an MCP server built into TeamCity 2026.1+ and the TeamCity CLI with an installable agent skill β which is the better default for most workflows. See How this compares to JetBrains' official tooling below before adopting.
Overview
The TeamCity MCP Server allows developers using AI-powered coding assistants (Claude Code, Cursor, Windsurf) to interact with TeamCity directly from their development environment via MCP tools.
Upgrading from 1.x? Version 2.0.0 moved 15 tools from Dev to Full mode, including queue management, agent compatibility checks, and server health monitoring. If you relied on these tools in Dev mode, switch to
MCP_MODE=fullor use runtime mode switching (v2.1.0+). See CHANGELOG.md for details.
Related MCP server: Jenkins MCP Server
Features
π Two Operational Modes
Dev Mode (default): Safe CI/CD operations (31 tools, ~14k context tokens)
Trigger builds and monitor status
Fetch build logs and inspect test failures
List projects, configurations, and queue
Read parameters and investigate problems
Full Mode: Complete infrastructure management (87 tools, ~26k context tokens)
All Dev mode features, plus:
Create and clone build configurations
Manage build steps, triggers, and dependencies
Configure VCS roots and agents
Full CRUD for parameters (build config, project, and output parameters)
Queue management and server administration
Runtime Mode Switching (v2.1.0+): Switch between modes at runtime using the get_mcp_mode and set_mcp_mode toolsβno restart required. MCP clients that support notifications will see the tool list update automatically.
See the Tools Mode Matrix for the complete list of 87 tools and their availability by mode.
π― Key Capabilities
Trigger and monitor builds, fetch logs, and inspect test failures
Token-based authentication to TeamCity; sensitive values redacted in logs
Modern architecture: simple, direct implementation with a singleton client
Performance-conscious: fast startup with minimal overhead
Clean codebase with clear module boundaries
How this compares to JetBrains' official tooling
As of October 2026 (TeamCity 2026.2, TeamCity CLI 1.6), JetBrains ships two first-party paths for AI agents, both generally available and officially supported:
Built-in MCP server β every TeamCity 2026.1+ server (Cloud and On-Premises) exposes an MCP endpoint at
<server-url>/app/mcp, so there's nothing to install. It's a deliberately small toolset: build logs, generic REST APIGET/POSTpassthrough tools, and (since 2026.2) pipeline tools. By default it runs in a safe mode where the agent can read and queue personal builds; an opt-in "brave mode" lets it send arbitrary RESTPOSTrequests and edit or delete pipelines. Since 2026.2 you can also sign in with OAuth instead of pasting an access token.TeamCity CLI β an open-source
teamcitycommand (TeamCity 2020.1+) with an installable agent skill (teamcity skill install) for Claude Code, Cursor, and other agents. It covers runs, logs, tests, the queue, agents, pools, projects, VCS roots, parameters, and pipelines, falls back to raw REST access viateamcity api, and has a read-only mode (TEAMCITY_RO=1). JetBrains' own docs describe it as the broader of the two options.
teamcity-mcp predates that tooling and overlaps with it heavily. The official tooling is the better default today. What teamcity-mcp still offers is narrower than it used to be:
An MCP server for servers older than 2026.1. If your client speaks only MCP and your TeamCity server predates the built-in endpoint, this still works (TeamCity 2020.1+).
Purpose-built MCP tools instead of a REST passthrough. It exposes 87 typed tools (gated by Dev/Full mode), so the agent doesn't need to know REST paths and locators β and it covers operations backed by
PUT/DELETE(such as enabling agents or deleting parameters), which the built-in MCP's genericGET/POSTtools don't reach.
JetBrains' tooling is evolving quickly, so rather than pin down a feature-by-feature comparison here (it would go stale fast), check the current docs and pick what fits:
TeamCity 2026.2 announcement β pipeline tools, brave mode, and OAuth for the built-in MCP
TeamCity 2026.1 announcement β where the official AI integration debuted
AI agent integration docs β the built-in MCP, its tools, and safe vs. brave mode
TeamCity CLI docs and agent skill β the terminal + agent-skill path
If you're comfortable with JetBrains' CLI, you may not need this project at all. It stays MIT-licensed and installable for whatever the built-ins don't yet reach β fork it if you want to take it further yourself.
Installation
Prerequisites
Node.js >= 20.10.0 (LTS versions 20, 22, 24 tested in CI)
TeamCity Server 2020.1+ with REST API access
TeamCity authentication token
Quick Start
# Clone the repository
git clone https://github.com/Daghis/teamcity-mcp.git
cd teamcity-mcp
# Install dependencies
npm install
# Configure environment
cp .env.example .env
# Edit .env with your TeamCity URL and token
# Run in development mode
npm run devnpm Package
Run the MCP server via npx (requires Node 20.x). Set your TeamCity environment variables inline or via a .env in the working directory.
# One-off run (inline envs)
TEAMCITY_URL="https://teamcity.example.com" \
TEAMCITY_TOKEN="<your_token>" \
MCP_MODE=dev \
npx -y @daghis/teamcity-mcp
# Or rely on .env in the current directory
npx -y @daghis/teamcity-mcpClaude Code
Add the MCP (relying on
.envfor configuration):claude mcp add teamcity -- npx -y @daghis/teamcity-mcp
With env vars (if not using .env):
claude mcp add teamcity -e TEAMCITY_URL="https://teamcity.example.com" -e TEAMCITY_TOKEN="tc_<your_token>" -- npx -y @daghis/teamcity-mcp
With CLI arguments (recommended for Windows):
claude mcp add teamcity -- npx -y @daghis/teamcity-mcp --url "https://teamcity.example.com" --token "tc_<your_token>" --mode dev
Add
-s userto install user-wide instead of project-scoped (default)Context usage (Opus 4.1, estimates):
Dev (default): ~14k tokens for MCP tools
Full (
MCP_MODE=full): ~26k tokens for MCP tools
Windows Users
On Windows, Claude Code's MCP configuration may not properly merge environment variables. Use CLI arguments as a workaround:
{
"mcpServers": {
"teamcity": {
"command": "npx",
"args": [
"-y",
"@daghis/teamcity-mcp",
"--url",
"https://teamcity.example.com",
"--token",
"YOUR_TOKEN"
]
}
}
}Or use a config file for better security (token not visible in process list):
{
"mcpServers": {
"teamcity": {
"command": "npx",
"args": ["-y", "@daghis/teamcity-mcp", "--config", "C:\\path\\to\\teamcity.env"]
}
}
}Configuration
Environment is validated centrally with Zod. Supported variables and defaults:
# Server Configuration
PORT=3000
NODE_ENV=development
LOG_LEVEL=info
# TeamCity Configuration (aliases supported)
TEAMCITY_URL=https://teamcity.example.com
TEAMCITY_TOKEN=your-auth-token
# Optional aliases:
# TEAMCITY_SERVER_URL=...
# TEAMCITY_API_TOKEN=...
# MCP Mode (dev or full)
MCP_MODE=dev
# Optional advanced TeamCity options (defaults shown)
# Connection
# TEAMCITY_TIMEOUT=30000
# TEAMCITY_MAX_CONCURRENT=10
# TEAMCITY_KEEP_ALIVE=true
# TEAMCITY_COMPRESSION=true
# Extra headers attached to every TeamCity request β useful when TeamCity
# sits behind a reverse proxy that gates access on custom headers (e.g.
# Cloudflare Zero Trust service tokens). One env var per header; the part
# after `TEAMCITY_HEADER_` is used verbatim as the HTTP header name.
# Example (note the literal hyphens β most shells need quoting):
# TEAMCITY_HEADER_CF-Access-Client-Id=<id>
# TEAMCITY_HEADER_CF-Access-Client-Secret=<secret>
# Retry
# TEAMCITY_RETRY_ENABLED=true
# TEAMCITY_MAX_RETRIES=3
# TEAMCITY_RETRY_DELAY=1000
# TEAMCITY_MAX_RETRY_DELAY=30000
# Pagination
# TEAMCITY_PAGE_SIZE=100
# TEAMCITY_MAX_PAGE_SIZE=1000
# TEAMCITY_AUTO_FETCH_ALL=false
# Circuit Breaker
# TEAMCITY_CIRCUIT_BREAKER=true
# TEAMCITY_CB_FAILURE_THRESHOLD=5
# TEAMCITY_CB_RESET_TIMEOUT=60000
# TEAMCITY_CB_SUCCESS_THRESHOLD=2These values are normalized in src/config/index.ts and consumed by src/teamcity/config.ts via helper getters.
Usage Examples
Once integrated with your AI coding assistant:
"Build the frontend on feature branch"
"Why did last night's tests fail?"
"Deploy staging with the latest build"
"Create a new build config for the mobile app"Tool Responses and Pagination
Responses: Tools now return consistent MCP content. For list/get operations, the
content[0].textcontains a JSON string. Example shape:{ "items": [...], "pagination": { "page": 1, "pageSize": 100 } }or{ "items": [...], "pagination": { "mode": "all", "pageSize": 100, "fetched": 250 } }.Pagination: Most list_* tools accept
pageSize,maxPages, andall:pageSizecontrols items per page.all: truefetches multiple pages up tomaxPages.Legacy
countonlist_buildsis kept for compatibility butpageSizeis preferred.
Validation and Errors
Input validation: Tool inputs are validated with Zod schemas; invalid input returns a structured error payload in the response content (JSON string) with
success: falseanderror.code = VALIDATION_ERROR.Error shaping: Errors are formatted consistently via a global handler. In production, messages may be sanitized; sensitive values (e.g., tokens) are redacted in logs.
API Usage
import { TeamCityAPI } from '@/api-client';
// Get the API client instance
const api = TeamCityAPI.getInstance();
// List projects
const projects = await api.listProjects();
// Get build status
const build = await api.getBuild('BuildId123');
// Trigger a new build
const newBuild = await api.triggerBuild('BuildConfigId', {
branchName: 'main',
});Note: The legacy helpers exported from
src/teamcity/index.tsremain only for compatibility and include placeholder implementations. Prefer the MCP tools (see the reference linked above) or theTeamCityAPIshown here when automating workflows.
Development
# Run tests
npm test
# Run tests with coverage
npm run test:coverage
# Lint code
npm run lint
# Format code
npm run format
# Type check
npm run typecheck
# Build for production
npm run build
# Analyze bundle for Codecov
npm run build:bundleBundle analysis in CI
The CI workflow runs npm run build:bundle and uploads the generated coverage/bundles JSON using codecov/codecov-action with the javascript-bundle plugin.
Project Structure
teamcity-mcp/
βββ src/ # Source code
β βββ tools.ts # All 87 MCP tool definitions
β βββ server.ts # MCP server setup
β βββ api-client.ts # TeamCity API singleton
β βββ config/ # Configuration with Zod validation
β βββ teamcity/ # Domain logic (build, agent, config managers)
β βββ teamcity-client/ # Auto-generated OpenAPI client
β βββ types/ # TypeScript type definitions
β βββ utils/ # Logger, MCP helpers, pagination
βββ tests/ # Unit and integration tests
βββ docs/ # Documentation
βββ scripts/ # Build and maintenance scriptsAPI Documentation
The MCP server exposes tools for TeamCity operations. Each tool corresponds to specific TeamCity REST API endpoints:
Build Management
TriggerBuild- Queue a new buildGetBuildStatus- Check build progressFetchBuildLog- Retrieve build logsListBuilds- Search builds by criteria
Test Analysis
ListTestFailures- Get failing testsGetTestDetails- Detailed test informationAnalyzeBuildProblems- Identify failure reasons
Configuration (Full Mode Only)
create_build_config- Create new TeamCity build configurations with full support for:VCS roots (Git, SVN, Perforce) with authentication
Build steps (script, Maven, Gradle, npm, Docker, PowerShell)
Triggers (VCS, schedule, finish-build, maven-snapshot)
Parameters and template-based configurations
See the MCP Tool Reference for argument details and additional options.
clone_build_config- Duplicate existing configurations into any project, preserving steps, triggers, and parameters.update_build_config- Adjust names, descriptions, artifact rules, and pause state for a configuration.manage_build_steps- Add, update, remove, or reorder build steps through a single tool surface.manage_build_triggers- Add or delete build triggers with full property support.create_vcs_root&add_vcs_root_to_build- Define VCS roots and attach them to build configurations.
See also: docs/TEAMCITY_MCP_TOOLS_GUIDE.md for expanded workflows and examples that align with the current MCP implementation.
Contributing
We welcome contributions! Please see CONTRIBUTING.md for details.
Security
Token Management
Configure
TEAMCITY_TOKENvia environment variable or config file (see.env.example); never commit real tokensUse a token with minimal required permissions; read-only tokens work for most Dev mode operations
Token-based authentication only; the MCP server does not support username/password
Logs redact sensitive values including tokens
Mode Selection
Prefer Dev mode unless Full mode is explicitly neededβthis limits the blast radius of any misconfiguration or prompt injection
Full mode enables destructive operations (project deletion, agent management) that cannot be easily undone
Network Security
Always use HTTPS for TeamCity connections; the server does not enforce this but strongly recommends it
The MCP server connects only to the configured TeamCity URL; no other network calls are made
AI Assistant Considerations
AI assistants could be manipulated via prompt injection in build logs, test output, or other TeamCity data
Dev mode's limited tool set reduces the impact of such attacks
All actions appear in TeamCity's audit log under the token's associated user
Build logs and test failure details may contain sensitive information (secrets, paths, internal URLs) that become visible to the AI assistant
Repository Security
This repository has GitHub secret scanning and push protection enabled. See SECURITY.md for vulnerability reporting.
Support
GitHub Issues: Report bugs or request features
Documentation: See the
docs/folder in this repository
Acknowledgments
JetBrains TeamCity for the excellent CI/CD platform
Anthropic for the Model Control Protocol specification
The open-source community for continuous support
See THIRD_PARTY_NOTICES.md for third-party licenses
Built with β€οΈ for developers who love efficient CI/CD workflows
Available Tools
32 toolsanalyze_build_problemsBRead-onlyIdempotent
Analyze and report build problems and failures.
Inputs: buildId, buildNumber, buildTypeId.
cancel_buildA
Cancel or stop a running or queued build, with optional comment and requeue flag. Returns the cancelled build; returns 404 if the build is unknown.
Inputs: buildId (required), comment, readdIntoQueue.
cancel_queued_buildA
Cancel a queued (not-yet-running) build. Idempotent; returns 404 if the build already started or was cancelled.
Inputs: buildId (required).
download_build_artifactARead-onlyIdempotent
Download a single build artifact, with base64, text, or streaming output. Returns the artifact bytes or stream metadata; returns 404 if the build or path is unknown.
Inputs: artifactPath (required), buildId, maxSize, encoding, +3 more.
download_build_artifactsARead-onlyIdempotent
Download multiple build artifacts, with base64, text, or streaming output. Returns per-artifact payloads or stream metadata; returns 404 if the build or any path is unknown.
Inputs: artifactPaths (required), buildId, maxSize, encoding, +3 more.
fetch_build_logBRead-onlyIdempotent
Fetch a build log. Supports line-based pagination and streaming output.
Inputs: page, tail, buildId, encoding, +7 more.
get_buildARead-onlyIdempotent
Get details of a specific build. Works for queued, running, and finished builds.
Inputs: buildId, buildNumber, buildTypeId. Returns: TeamCity build representation.
get_build_configBRead-onlyIdempotent
Get details of a build configuration.
Inputs: buildTypeId (required). Returns: TeamCity build configuration (buildType) representation.
get_build_resultsARead-onlyIdempotent
Get detailed results of a build. Optionally includes tests, artifacts, changes, statistics, and dependencies.
Inputs: buildId, buildNumber, buildTypeId, artifactFilter, +6 more. Returns: Rich build result bundle assembled by BuildResultsManager. The core build summaβ¦
get_build_statusBRead-onlyIdempotent
Get build status. Optionally includes test and problem summaries plus queue context.
Inputs: buildId, buildNumber, buildTypeId, includeTests, +3 more. Returns: Aggregated status for a queued, running, or finished build.
get_mcp_modeARead-onlyIdempotent
Get the current MCP mode. Dev mode is read-only; full mode enables all operations.
Inputs: no named parameters.
get_projectBRead-onlyIdempotent
Get details of a specific project.
Inputs: projectId (required). Returns: TeamCity project representation.
get_server_infoARead-onlyIdempotent
Get TeamCity server info including version, build number, and state.
Inputs: no named parameters.
get_test_detailsCRead-onlyIdempotent
Get detailed information about test failures.
Inputs: buildId, testNameId, buildNumber, buildTypeId.
list_branchesARead-onlyIdempotent
List branches for a project or build configuration.
Inputs: projectId, buildTypeId.
list_build_artifactsARead-onlyIdempotent
List artifact files and directories for a build, optionally browsing into subdirectories. Returns an array of artifact entries with name, path, size, and isDirectory flag.
Inputs: path, buildId, extension, nameFilter, +4 more.
list_build_configsBRead-onlyIdempotent
List build configurations. Supports pagination and locator filtering.
Inputs: all, fields, locator, maxPages, +2 more. Returns: items, pagination
list_buildsARead-onlyIdempotent
List TeamCity builds. Supports pagination and locator filtering.
Inputs: all, count, branch, fields, +6 more. Returns: items, pagination
list_changesARead-onlyIdempotent
List VCS changes. Supports pagination.
Inputs: all, fields, buildId, locator, +3 more.
list_investigationsBRead-onlyIdempotent
List open investigations. Supports pagination.
Inputs: all, fields, locator, maxPages, +4 more.
list_muted_testsBRead-onlyIdempotent
List muted tests. Supports pagination.
Inputs: all, fields, locator, maxPages, +4 more.
list_parametersARead-onlyIdempotent
List parameters for a build configuration.
Inputs: buildTypeId (required).
list_problem_occurrencesBRead-onlyIdempotent
List build problem occurrences. Supports pagination.
Inputs: all, fields, buildId, locator, +3 more.
list_problemsBRead-onlyIdempotent
List build problems. Supports pagination.
Inputs: all, fields, buildId, locator, +3 more.
list_project_hierarchyARead-onlyIdempotent
List project hierarchy showing parent-child relationships.
Inputs: rootProjectId.
list_projectsARead-onlyIdempotent
List TeamCity projects. Supports pagination and locator filtering.
Inputs: all, fields, locator, maxPages, +2 more. Returns: items, pagination
list_queued_buildsARead-onlyIdempotent
List queued builds. Supports TeamCity queue locator filtering and pagination.
Inputs: all, fields, locator, maxPages, +1 more.
list_test_failuresARead-onlyIdempotent
List test failures for a build. Supports pagination.
Inputs: all, fields, buildId, maxPages, +3 more.
pingARead-onlyIdempotent
Test MCP server connectivity. Returns a confirmation echo and optional message.
Inputs: message.
set_mcp_modeAIdempotent
Switch MCP mode at runtime. Returns previous and current modes with the updated tool count; idempotent and notifies clients of the list change.
Inputs: mode (required).
trigger_buildA
Trigger a new build; runs asynchronously, use wait_for_build to monitor. Returns the queued build id; returns 404 if buildTypeId is unknown.
Inputs: buildTypeId (required), comment, branchName, properties.
wait_for_buildARead-only
Wait for a build to reach a terminal state (finished, canceled, failed). Long-running; polls until completion or timeout.
Inputs: buildId, timeout, buildNumber, buildTypeId, +3 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelogβ¦
TDQS
Scored across 32 tools
Most tools map to a distinct resource+action (projects, build configs, builds, queue, tests, problems, artifacts), and descriptions clarify close pairs like get_build vs get_build_status vs get_build_results. However, cancel_queued_build overlaps heavily with cancel_build (which explicitly handles 'running or queued' builds), and list_problems vs list_problem_occurrences plus get_test_details vs list_test_failures have blurry boundaries.
Every tool follows a consistent snake_case verb_noun pattern (list_projects, get_build, trigger_build, download_build_artifact), with only trivial exceptions like ping. Singular/plural distinctions (download_build_artifact vs download_build_artifacts) are used predictably.
At 32 tools the surface is heavy for any single agent context, though the CI-server domain is genuinely broad (projects, configs, queue, tests, problems, artifacts, server ops). Some tools feel like bloat or could be merged, e.g. cancel_queued_build alongside cancel_build, and the singular/plural artifact download pair.
Core CI workflows are well covered: inspect projects/configs, list/trigger/cancel/wait on builds, fetch logs and artifacts, and review tests, problems, changes, and investigations. Notable gaps remain around agents (why a build is queued, agent status), VCS roots, tags/pinning, and any create/update/delete of projects or build configurations, which limits write-side lifecycle coverage.
Maintenance
Related MCP Connectors
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Connect AI agents to CloudBees Unify: feature flags, CI/CD, release orchestration, and security
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with Jenkins CI/CD systems through natural language, providing build management, job monitoring, log analysis, and debugging capabilities.MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with Jenkins CI/CD systems for build management, job monitoring, console log analysis, and debugging through natural language commands.2MIT
- AlicenseBqualityBmaintenanceEnables AI assistants to interact with Atlassian Bamboo CI/CD, allowing natural language queries to check build status, fetch logs, trigger builds, and manage deployments.27791 npm6MIT
- AlicenseNot gradedqualityDmaintenanceEnables management of TeamCity CI/CD operations through natural language commands, including builds, projects, tests, artifacts, and more.15 npmMIT