Skip to main content
Glama
TeamCity MCP Server
by Daghis

TeamCity MCP Server

CI CodeQL codecov License: MIT

A Model Control Protocol (MCP) server that bridges AI coding assistants with JetBrains TeamCity CI/CD server, exposing TeamCity operations as MCP tools.

NOTE

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=full or 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 API GET/POST passthrough 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 REST POST requests 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 teamcity command (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 via teamcity 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 generic GET/POST tools 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:

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 dev

npm 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-mcp

Claude Code

  • Add the MCP (relying on .env for 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 user to 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=2

These 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].text contains 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, and all:

    • pageSize controls items per page.

    • all: true fetches multiple pages up to maxPages.

    • Legacy count on list_builds is kept for compatibility but pageSize is 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: false and error.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.ts remain only for compatibility and include placeholder implementations. Prefer the MCP tools (see the reference linked above) or the TeamCityAPI shown 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:bundle

Bundle 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 scripts

API Documentation

The MCP server exposes tools for TeamCity operations. Each tool corresponds to specific TeamCity REST API endpoints:

Build Management

  • TriggerBuild - Queue a new build

  • GetBuildStatus - Check build progress

  • FetchBuildLog - Retrieve build logs

  • ListBuilds - Search builds by criteria

Test Analysis

  • ListTestFailures - Get failing tests

  • GetTestDetails - Detailed test information

  • AnalyzeBuildProblems - 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_TOKEN via environment variable or config file (see .env.example); never commit real tokens

  • Use 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

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 tools
analyze_build_problemsB
Read-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_artifactA
Read-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_artifactsA
Read-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_logB
Read-onlyIdempotent

Fetch a build log. Supports line-based pagination and streaming output.

Inputs: page, tail, buildId, encoding, +7 more.

get_buildA
Read-onlyIdempotent

Get details of a specific build. Works for queued, running, and finished builds.

Inputs: buildId, buildNumber, buildTypeId. Returns: TeamCity build representation.

get_build_configB
Read-onlyIdempotent

Get details of a build configuration.

Inputs: buildTypeId (required). Returns: TeamCity build configuration (buildType) representation.

get_build_resultsA
Read-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_statusB
Read-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_modeA
Read-onlyIdempotent

Get the current MCP mode. Dev mode is read-only; full mode enables all operations.

Inputs: no named parameters.

get_projectB
Read-onlyIdempotent

Get details of a specific project.

Inputs: projectId (required). Returns: TeamCity project representation.

get_server_infoA
Read-onlyIdempotent

Get TeamCity server info including version, build number, and state.

Inputs: no named parameters.

get_test_detailsC
Read-onlyIdempotent

Get detailed information about test failures.

Inputs: buildId, testNameId, buildNumber, buildTypeId.

list_branchesA
Read-onlyIdempotent

List branches for a project or build configuration.

Inputs: projectId, buildTypeId.

list_build_artifactsA
Read-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_configsB
Read-onlyIdempotent

List build configurations. Supports pagination and locator filtering.

Inputs: all, fields, locator, maxPages, +2 more. Returns: items, pagination

list_buildsA
Read-onlyIdempotent

List TeamCity builds. Supports pagination and locator filtering.

Inputs: all, count, branch, fields, +6 more. Returns: items, pagination

list_changesA
Read-onlyIdempotent

List VCS changes. Supports pagination.

Inputs: all, fields, buildId, locator, +3 more.

list_investigationsB
Read-onlyIdempotent

List open investigations. Supports pagination.

Inputs: all, fields, locator, maxPages, +4 more.

list_muted_testsB
Read-onlyIdempotent

List muted tests. Supports pagination.

Inputs: all, fields, locator, maxPages, +4 more.

list_parametersA
Read-onlyIdempotent

List parameters for a build configuration.

Inputs: buildTypeId (required).

list_problem_occurrencesB
Read-onlyIdempotent

List build problem occurrences. Supports pagination.

Inputs: all, fields, buildId, locator, +3 more.

list_problemsB
Read-onlyIdempotent

List build problems. Supports pagination.

Inputs: all, fields, buildId, locator, +3 more.

list_project_hierarchyA
Read-onlyIdempotent

List project hierarchy showing parent-child relationships.

Inputs: rootProjectId.

list_projectsA
Read-onlyIdempotent

List TeamCity projects. Supports pagination and locator filtering.

Inputs: all, fields, locator, maxPages, +2 more. Returns: items, pagination

list_queued_buildsA
Read-onlyIdempotent

List queued builds. Supports TeamCity queue locator filtering and pagination.

Inputs: all, fields, locator, maxPages, +1 more.

list_test_failuresA
Read-onlyIdempotent

List test failures for a build. Supports pagination.

Inputs: all, fields, buildId, maxPages, +3 more.

pingA
Read-onlyIdempotent

Test MCP server connectivity. Returns a confirmation echo and optional message.

Inputs: message.

set_mcp_modeA
Idempotent

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_buildA
Read-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

    A3.5/5.0

    Scored across 32 tools

    Disambiguation4/5

    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.

    Naming Consistency5/5

    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.

    Tool Count3/5

    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.

    Completeness3/5

    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

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables AI assistants to interact with Jenkins CI/CD systems through natural language, providing build management, job monitoring, log analysis, and debugging capabilities.
      MIT
    • A
      license
      B
      quality
      B
      maintenance
      Enables AI assistants to interact with Atlassian Bamboo CI/CD, allowing natural language queries to check build status, fetch logs, trigger builds, and manage deployments.
      27
      791 npm
      6
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables management of TeamCity CI/CD operations through natural language commands, including builds, projects, tests, artifacts, and more.
      15 npm
      MIT