# Reported issues for teamcity

Pod holds 23 of 79 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [teamcity](/mcp/teamcity).

## 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

### feat(teamcity): explore streaming artifact downloads

## Summary
Claude suggested (PR #147 review) evaluating streaming support for artifact downloads in `ArtifactManager`. We currently buffer entire responses when `downloadArtifacts` is enabled, which can inflate memory usage for large files.

## Why
- Reduce memory pressure for large artifact downloads.
- Lay groundwork for exposing streamed responses to callers (e.g., CLI tools).

## Proposal
- Investigate whether the TeamCity REST API supports chunked downloads via axios streams.
- Prototype a 

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/151) · 2025-09-19 · closed · 4 comments

### refactor(teamcity): migrate specialized managers to unified client

Parent: #106

## Summary
Refactor the specialized managers that still spin up custom axios instances so they consume the unified adapter and inherit its auth/retry behavior.

## Scope
- Update the following modules to use `TeamCityClientAdapter` (including `client.http`) instead of constructing local axios instances or reading tokens directly:
  - `build-step-manager.ts`
  - `build-trigger-manager.ts`
  - `test-problem-reporter.ts`
  - `artifact-manager.ts`
- Adjust constructor signatures and in

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/117) · 2025-09-16 · closed · 4 comments

### test: restore coverage for tools and managers

## Summary
Current coverage numbers are inflated because the Jest config excludes the entire tool layer and TeamCity managers from instrumentation. We need to re-enable coverage gradually and backfill missing tests so the reported metrics reflect real health.

## Why
- `jest.config.js` omits `src/tools.ts`, all of `src/teamcity/**/*.ts`, and other layers from `collectCoverageFrom` (`jest.config.js:28-60`).
- Many suites already exercise these modules, but with coverage off we cannot detect dead 

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/109) · 2025-09-16 · 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:

> `<Verb> <resource

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/469) · 2026-04-23 · closed · 0 comments

### Add `outputSchema` to tool registrations for tools that return structured data

## Background

The MCP spec supports an `outputSchema` field on tool definitions so agents know the shape of the response without having to introspect or guess. We currently rely on TypeScript types internally but never expose them as JSON Schema to the agent. This forces models to parse responses heuristically and creates room for hallucinated field access (e.g. `.id` vs `.buildId` vs `.build.id`).

This was an implicit gap noted in the Glama review (https://glama.ai/mcp/servers/Daghis/teamcity

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/468) · 2026-04-23 · closed · 0 comments

### Add agent removal/deletion tool

## Summary

The MCP server provides tools to list, authorize, enable/disable, and assign agents to pools, but there is no tool to **remove (delete) an agent** from the TeamCity server. This is needed when ghost/stale agent entries accumulate (e.g., after re-provisioning agents that lose their authorization tokens).

## Use Case

When build agents are re-provisioned and their `authorizationToken` in `buildAgent.properties` is reset, TeamCity treats them as new agents and appends suffixes to avoid

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/439) · 2026-03-24 · closed · 0 comments

### Feature request: wait_for_build tool for blocking build completion

## Summary

Add a `wait_for_build` tool that blocks until a build finishes (or times out), returning the final build status. This would replace the current pattern of repeated `sleep` + `get_build_status` polling that LLM agents must use today.

## Motivation

When an LLM agent triggers a build and needs the result before proceeding, the only option today is:

1. `trigger_build` → get buildId
2. `sleep 60`
3. `get_build_status` → still queued/running
4. `sleep 60`
5. `get_build_status` → still r

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/430) · 2026-03-18 · closed · 0 comments

### fetch_build_log pagination: cannot retrieve pages beyond the first

## Summary

`fetch_build_log` returns paginated results (500 lines per page) with metadata indicating more pages exist, but there is no way to request subsequent pages. The tool rejects pagination parameters with validation errors.

## Steps to Reproduce

1. Fetch a build log that exceeds 500 lines:
   ```json
   {"buildId": "28125"}
   ```
2. Response includes pagination metadata:
   ```json
   {
     "meta": {
       "buildId": "28125",
       "page": 1,
       "pageSize": 500,
       "startLi

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/429) · 2026-03-18 · closed · 0 comments

### set_vcs_root_property silently fails to persist branchSpec

## Summary

`set_vcs_root_property` reports success when setting `branchSpec` on a Git VCS root, but the value does not persist. The TeamCity UI shows the Branch specification field as blank after the API call. Similarly, `update_vcs_root_properties` with a `branchSpec` parameter reports success and even returns `"updated": 3` but the branchSpec is not saved.

## Steps to Reproduce

1. Have an existing Git VCS root (e.g., `ThinQWatch_ThinqWatch`) with no branch specification configured
2. Call `

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/428) · 2026-03-18 · closed · 0 comments

### Absent .env.example .env

### Bug Description

.env.example .env - the file is not in the repo

### Expected Behavior

.env.example .env - the file is in the repo

### Steps to Reproduce

.env.example .env - no file in the repo

### Version

last version

### TeamCity Version

_No response_

### MCP Client

Claude Desktop

### Relevant Logs

```shell

```

### Additional Context

_No response_

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/409) · 2026-03-08 · closed · external user · 1 comment

### No tool for managing project SSH keys (upload/list/delete)

## Summary

There is no MCP tool to upload, list, or delete SSH keys scoped to a TeamCity project. This is needed when configuring build features like `ssh-agent-build-feature` that reference a named key — if that key only exists in a sibling project, the build fails with `Cannot find ssh key '<name>'` and there's no way to fix it through the MCP API.

## TeamCity REST API

The REST API supports full SSH key management:

| Operation | Endpoint |
|---|---|
| Upload key | `POST /app/rest/projects/

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/407) · 2026-03-01 · closed · 0 comments

### manage_build_dependencies: snapshot dep options ignored on add; update returns 400

## Summary

Two related deficiencies in `manage_build_dependencies` for snapshot dependencies:

1. **Options are silently ignored on `add`** — properties passed in the `options` object (e.g. `take-successful-builds-only`) are not applied; TeamCity returns its defaults instead.
2. **`update` returns HTTP 400** — attempting to fix the missing options via `update` fails with a 400 error, making the values uncorrectable through the MCP API.

---

## Steps to Reproduce

### 1. Create a snapshot depen

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/406) · 2026-03-01 · closed · 0 comments

### dotenv stdout pollution report

I think I'm having trouble with this, specifically the dotenv stdout pollution, even though I'm up to date.

Could this be because I have an .env file present in the current directory?

Running the mcp server showing both stdout and stderr (and the version I'm running):
```
$ bunx @daghis/teamcity-mcp --version
[dotenv@17.2.4] injecting env (0) from .env -- tip: 🔄 add secrets lifecycle management: https://dotenvx.com/ops
teamcity-mcp v2.2.1
```

Suppressing stderr, to get just stdout,

[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/400) · 2026-02-18 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/Daghis/teamcity-mcp/issues).