# teamcity MCP Server MCP server exposing JetBrains TeamCity CI/CD workflows to AI coding assistants **Publisher claimed.** No tool list reported, and Pod has not connected to this server. ## Status Pod has not dialled teamcity yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim. ## Connect Published as `@daghis/teamcity-mcp` on npm. Runs locally. ## Known issues **79 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12. ### Most discussed ### refactor(teamcity): unify adapter-based client initialization Parent: #106 ## Summary Rework the adapter and initialization flow so every consumer in `src/teamcity` can depend solely on the unified `TeamCityAPI`. The current `TeamCityClient` wrapper is still the public entry point, and `createAdapterFromTeamCityAPI` only exposes the builds API. ## Scope - Extend `createAdapterFromTeamCityAPI` to surface the modules and helper methods provided by the expanded `TeamCityAPI`, including the shared axios instance. - Update `src/teamcity/index.ts` so `initiali [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/114) · 2025-09-16 · closed · 11 comments ### refactor(teamcity): route build results/list through unified client Parent: #106 ## Summary Eliminate the remaining direct axios usage inside the reporting flows so they rely on the shared adapter/axios instance. This ensures consistent auth, retries, and logging for build insights. ## Scope - Update these modules to call adapter APIs (or the shared `http` instance) instead of creating ad-hoc axios clients: - `build-results-manager.ts` - `build-list-manager.ts` - `build-results-manager` helper methods that fetch artifacts/statistics/changes/dependencies. [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/116) · 2025-09-16 · closed · 8 comments ### refactor(teamcity): migrate build/project managers to adapter Parent: #106 ## Summary Convert the core build/project management layers to depend on the new adapter so they no longer import `TeamCityClient`. This unlocks removal of the legacy wrapper and aligns constructor signatures across the module. ## Scope - Update the following modules to type against `TeamCityClientAdapter` and consume the expanded surface from #113/#114: - `build-config-manager.ts` - `build-configuration-update-manager.ts` - `build-configuration-resolver.ts` - `build-confi [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/115) · 2025-09-16 · closed · 7 comments ### Add MCP `annotations` (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) to every tool registration ## Background Glama's automated MCP review (https://glama.ai/mcp/servers/Daghis/teamcity-mcp/score) flagged `behavioral_transparency` on 26 of 27 reviewed tools. The root cause is that none of our tool registrations include the MCP-spec `annotations` field. Without these, agents cannot tell which tools are safe to retry, which mutate state, or which are destructive, so they conservatively prompt for confirmation on everything (or worse, plan poorly). This is the highest-leverage improvement av [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/467) · 2026-04-23 · closed · 4 comments ### Investigate whether the TeamCity REST API supports chunked downloads via axios streams ## Summary Subtask of #151 focused on the discovery work needed before we can prototype streaming artifact downloads. We need to verify whether the TeamCity REST API, and specifically the endpoints backing `downloadFileOfBuild`, can deliver chunked responses we can tap into via Axios streams. ## Goals - Confirm which TeamCity REST endpoints support HTTP streaming or range requests for artifact content. - Evaluate client-side requirements (Axios adapters, responseType options, Node.js stream han [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/157) · 2025-09-19 · closed · 4 comments ### Most recent ### Build scriptable REST API coverage matrix (scripts/audit-rest-coverage.ts + docs/rest-coverage.md) ## Background We don't have a current, accurate picture of which TeamCity REST operations are exposed via our MCP tools vs. which are missing. Today, this is a manual audit that drifts the moment we add a tool or TeamCity bumps a version. A rough first-cut: TeamCity exposes ~200 unique REST operations across 30 generated API namespaces. teamcity-mcp has 96 tools. Coverage is roughly half by raw op count, but the comparison is uneven because we sensibly collapse many granular REST endpoints int [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/503) · 2026-05-11 · closed · 1 comment ### Strategic gap-coverage initiative (epic) ## Why this exists teamcity-mcp grew to 96 tools without a written design posture. JetBrains 2026.1 now ships a built-in MCP endpoint (3 tools: build log, generic REST GET, build trigger), which forces a clearer answer to "why does teamcity-mcp exist?" — for users picking between the two and for ourselves when adding new tools. This epic tracks a three-step initiative to make those decisions explicit and data-driven instead of ad-hoc. ## Sub-issues (in execution order) - [ ] #502 — Commit to [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/501) · 2026-05-11 · closed · 1 comment ### feat: add list_build_artifacts tool for subdirectory browsing ## Problem The current artifact tools can list top-level artifacts but cannot browse into subdirectories: 1. `get_build_results` shows directories (e.g. `okd` with size: 0) but doesn't list their children — only top-level entries are returned. 2. `download_build_artifact` expects a full file path (e.g. `okd/deploy.yaml`), but without a way to list directory contents, the exact filenames are unknown. 3. The TeamCity REST API supports listing subdirectory contents via the `basePath` parameter on [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/490) · 2026-04-28 · closed · outside contributor · 0 comments ### Add targeted sibling-disambiguation only where tool names genuinely collide ## Background Glama's review wanted "use this when not …" disambiguators on every tool. Applying that everywhere bloats descriptions and hurts the agent's token budget. But there are a small number of cases where two sibling tools have genuinely overlapping names and the agent could plausibly pick the wrong one. This issue covers only those targeted cases — a deliberately narrow scope. ## Goal For each of the cases below, add a single short disambiguating clause (≤10 words) explaining when t [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/471) · 2026-04-23 · closed · 1 comment ### Mutating tools must disclose principal return value and likely failure mode ## Background For mutating tools (anything with `readOnlyHint: false` after issue #467 lands), the agent needs to know what comes back on success and what to expect on common failures. Today most mutator descriptions stop at the verb. The Glama review's most defensible criticism was that mutation tools (`trigger_build`, `cancel_*`, `update_*`, `delete_*`, etc.) provide no behavioral disclosure for write paths. ## Goal Every tool registered with `readOnlyHint: false` ends its description with [Read the thread](https://github.com/Daghis/teamcity-mcp/issues/470) · 2026-04-23 · closed · 0 comments ### Adopt a single description template across all MCP tools ## Background Tool descriptions today range from 3 words ("Test MCP server connectivity") to short paragraphs, with no consistent structure. Agents pick tools by pattern-matching on names + descriptions, and inconsistent shape makes that less reliable. The Glama review (https://glama.ai/mcp/servers/Daghis/teamcity-mcp/score) penalized this implicitly via the `conciseness_structure` ↔ `contextual_completeness` axis. ## Goal Every tool description follows the same skeleton: > `