pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

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.

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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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:

` <resource

Read the thread · 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 · 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 · 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 · 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:
    {"buildId": "28125"}
  2. Response includes pagination metadata:
    {
  "meta": {
    "buildId": "28125",
    "page": 1,
    "pageSize": 500,
    "startLi

Read the thread · 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 · 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

Additional Context

No response

Read the thread · 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 · 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 · 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 · 2026-02-18 · closed · 1 comment

The remaining reports are on the project's issue tracker.