Decide the mode first: dev is the default and stays on the read-and-run side, while full opens up creating and editing build configurations, steps, triggers and parameters. The author now describes the project as stable and in low-key maintenance and points at JetBrains' own built-in TeamCity MCP for read-and-rerun work, so the case for this one rests on that write surface.
An MCP server over TeamCity's REST API. It connects to your own TeamCity server with a personal access token, and keeps the write operations behind a mode switch so the default surface is read-and-run only.
- A build end to end: trigger one on a branch with a comment and properties, wait until it reaches a terminal state, then read status and detailed results
- Build logs with line-based paging — fetch a page, tail a fixed number of lines, or write the log straight to a path
- Failure triage: list the failing tests for a build, open one test's details, and pull build problems and their occurrences
- Artifacts: list what a build produced, browse into subdirectories, and download one or many as base64, text or a stream
- The project side: projects and their hierarchy, build configurations, branches, parameters, VCS changes, the queue, open investigations and muted tests
- Cancelling work: drop a queued build, or stop a running one and optionally put it back in the queue
- Set MCP_MODE to full and the write surface appears — create_project, clone_build_config, manage_build_steps, manage_build_triggers, add_parameter and the rest — with get_mcp_mode and set_mcp_mode switching modes without a restart
Node.js >= 20.10.0 and a TeamCity Server 2020.1+ with REST API access. Two required environment variables: TEAMCITY_URL for the server and TEAMCITY_TOKEN for a personal access token. MCP_MODE selects the tool surface — dev by default, full for the write operations. Runs over stdio, launched with npx -y @daghis/teamcity-mcp.
One command plus a key — npx -y @daghis/teamcity-mcp, then supply credentials