{ "SchemaVersion": "1", "Kind": "DirectoryEntry", "SubjectType": "mcp-server", "Slug": "teamcity", "Name": "teamcity", "Title": "teamcity MCP Server | Pod", "Description": "MCP server exposing JetBrains TeamCity CI/CD workflows to AI coding assistants", "CanonicalUrl": "https://askpod.ai/mcp/teamcity", "MarkdownUrl": "https://askpod.ai/mcp/teamcity.md", "JsonUrl": "https://askpod.ai/mcp/teamcity.json", "DatePublished": "2026-09-01T14:35:04.245Z", "DateModified": "2026-09-01T14:35:04.245Z", "Publisher": "github.com", "RegistryName": "io.github.Daghis/teamcity", "WebsiteUrl": "https://github.com/Daghis/teamcity-mcp", "RepositoryUrl": "https://github.com/Daghis/teamcity-mcp", "VerificationStatus": "unverified", "Identities": [ { "Namespace": "package", "Value": "npm:@daghis/teamcity-mcp" }, { "Namespace": "github_repository", "Value": "https://github.com/Daghis/teamcity-mcp" } ], "Sources": [ { "Source": "official_mcp_registry", "ExternalId": "io.github.Daghis/teamcity", "FirstSeenAt": "2026-08-29T23:19:47.186Z", "LastSeenAt": "2026-09-01T02:56:46.045Z" } ], "Categories": [], "FirstParty": true, "Deployments": [ { "Kind": "package", "PackageRegistry": "npm", "PackageIdentifier": "@daghis/teamcity-mcp", "PackageVersion": "2.12.1", "ConfigSnippet": "{\n \"mcpServers\": {\n \"teamcity\": {\n \"command\": \"npx\",\n \"args\": [\n \"-y\",\n \"@daghis/teamcity-mcp\"\n ]\n }\n }\n}" } ], "Tools": { "Claimed": [], "ClaimedCount": 0, "Observed": null, "ObservedCount": null, "Verified": false, "Mismatch": null }, "Measured": null, "Usage": { "Registry": "npm", "DownloadsLast30d": 4549 }, "IssueTotal": 79, "IssuesHeld": 23, "Issues": [ { "Title": "refactor(teamcity): unify adapter-based client initialization", "Excerpt": "Parent: #106\n\n## Summary\nRework 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.\n\n## Scope\n- Extend `createAdapterFromTeamCityAPI` to surface the modules and helper methods provided by the expanded `TeamCityAPI`, including the shared axios instance.\n- Update `src/teamcity/index.ts` so `initiali", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/114", "PublishedAt": "2025-09-16T19:19:26.000Z", "State": "closed", "Comments": 11, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "refactor(teamcity): route build results/list through unified client", "Excerpt": "Parent: #106\n\n## Summary\nEliminate 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.\n\n## Scope\n- Update these modules to call adapter APIs (or the shared `http` instance) instead of creating ad-hoc axios clients:\n - `build-results-manager.ts`\n - `build-list-manager.ts`\n - `build-results-manager` helper methods that fetch artifacts/statistics/changes/dependencies.", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/116", "PublishedAt": "2025-09-16T19:20:07.000Z", "State": "closed", "Comments": 8, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "refactor(teamcity): migrate build/project managers to adapter", "Excerpt": "Parent: #106\n\n## Summary\nConvert 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.\n\n## Scope\n- Update the following modules to type against `TeamCityClientAdapter` and consume the expanded surface from #113/#114:\n - `build-config-manager.ts`\n - `build-configuration-update-manager.ts`\n - `build-configuration-resolver.ts`\n - `build-confi", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/115", "PublishedAt": "2025-09-16T19:19:46.000Z", "State": "closed", "Comments": 7, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Add MCP `annotations` (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) to every tool registration", "Excerpt": "## Background\n\nGlama'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).\n\nThis is the highest-leverage improvement av", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/467", "PublishedAt": "2026-04-23T11:55:25.000Z", "State": "closed", "Comments": 4, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Investigate whether the TeamCity REST API supports chunked downloads via axios streams", "Excerpt": "## Summary\nSubtask 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.\n\n## Goals\n- Confirm which TeamCity REST endpoints support HTTP streaming or range requests for artifact content.\n- Evaluate client-side requirements (Axios adapters, responseType options, Node.js stream han", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/157", "PublishedAt": "2025-09-19T21:04:10.000Z", "State": "closed", "Comments": 4, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "feat(teamcity): explore streaming artifact downloads", "Excerpt": "## Summary\nClaude 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.\n\n## Why\n- Reduce memory pressure for large artifact downloads.\n- Lay groundwork for exposing streamed responses to callers (e.g., CLI tools).\n\n## Proposal\n- Investigate whether the TeamCity REST API supports chunked downloads via axios streams.\n- Prototype a ", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/151", "PublishedAt": "2025-09-19T18:51:25.000Z", "State": "closed", "Comments": 4, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "refactor(teamcity): migrate specialized managers to unified client", "Excerpt": "Parent: #106\n\n## Summary\nRefactor the specialized managers that still spin up custom axios instances so they consume the unified adapter and inherit its auth/retry behavior.\n\n## Scope\n- Update the following modules to use `TeamCityClientAdapter` (including `client.http`) instead of constructing local axios instances or reading tokens directly:\n - `build-step-manager.ts`\n - `build-trigger-manager.ts`\n - `test-problem-reporter.ts`\n - `artifact-manager.ts`\n- Adjust constructor signatures and in", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/117", "PublishedAt": "2025-09-16T19:20:26.000Z", "State": "closed", "Comments": 4, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "test: restore coverage for tools and managers", "Excerpt": "## Summary\nCurrent 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.\n\n## Why\n- `jest.config.js` omits `src/tools.ts`, all of `src/teamcity/**/*.ts`, and other layers from `collectCoverageFrom` (`jest.config.js:28-60`).\n- Many suites already exercise these modules, but with coverage off we cannot detect dead ", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/109", "PublishedAt": "2025-09-16T18:24:23.000Z", "State": "closed", "Comments": 4, "Reporter": "Maintainer", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Build scriptable REST API coverage matrix (scripts/audit-rest-coverage.ts + docs/rest-coverage.md)", "Excerpt": "## Background\n\nWe 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.\n\nA 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", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/503", "PublishedAt": "2026-05-11T19:57:57.000Z", "State": "closed", "Comments": 1, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Strategic gap-coverage initiative (epic)", "Excerpt": "## Why this exists\n\nteamcity-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.\n\nThis epic tracks a three-step initiative to make those decisions explicit and data-driven instead of ad-hoc.\n\n## Sub-issues (in execution order)\n\n- [ ] #502 — Commit to", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/501", "PublishedAt": "2026-05-11T19:57:34.000Z", "State": "closed", "Comments": 1, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "feat: add list_build_artifacts tool for subdirectory browsing", "Excerpt": "## Problem\n\nThe current artifact tools can list top-level artifacts but cannot browse into subdirectories:\n\n1. `get_build_results` shows directories (e.g. `okd` with size: 0) but doesn't list their children — only top-level entries are returned.\n2. `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.\n3. The TeamCity REST API supports listing subdirectory contents via the `basePath` parameter on", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/490", "PublishedAt": "2026-04-28T03:30:04.000Z", "State": "closed", "Comments": 0, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Add targeted sibling-disambiguation only where tool names genuinely collide", "Excerpt": "## Background\n\nGlama'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.\n\nThis issue covers only those targeted cases — a deliberately narrow scope.\n\n## Goal\n\nFor each of the cases below, add a single short disambiguating clause (≤10 words) explaining when t", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/471", "PublishedAt": "2026-04-23T11:56:30.000Z", "State": "closed", "Comments": 1, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Mutating tools must disclose principal return value and likely failure mode", "Excerpt": "## Background\n\nFor 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.\n\n## Goal\n\nEvery tool registered with `readOnlyHint: false` ends its description with ", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/470", "PublishedAt": "2026-04-23T11:56:13.000Z", "State": "closed", "Comments": 0, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Adopt a single description template across all MCP tools", "Excerpt": "## Background\n\nTool 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.\n\n## Goal\n\nEvery tool description follows the same skeleton:\n\n> ` '` and there's no way to fix it through the MCP API.\n\n## TeamCity REST API\n\nThe REST API supports full SSH key management:\n\n| Operation | Endpoint |\n|---|---|\n| Upload key | `POST /app/rest/projects/", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/407", "PublishedAt": "2026-03-01T14:56:01.000Z", "State": "closed", "Comments": 0, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "manage_build_dependencies: snapshot dep options ignored on add; update returns 400", "Excerpt": "## Summary\n\nTwo related deficiencies in `manage_build_dependencies` for snapshot dependencies:\n\n1. **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.\n2. **`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.\n\n---\n\n## Steps to Reproduce\n\n### 1. Create a snapshot depen", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/406", "PublishedAt": "2026-03-01T14:43:17.000Z", "State": "closed", "Comments": 0, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "dotenv stdout pollution report", "Excerpt": "I think I'm having trouble with this, specifically the dotenv stdout pollution, even though I'm up to date.\r\n\r\nCould this be because I have an .env file present in the current directory?\r\n\r\nRunning the mcp server showing both stdout and stderr (and the version I'm running):\r\n```\r\n$ bunx @daghis/teamcity-mcp --version\r\n[dotenv@17.2.4] injecting env (0) from .env -- tip: 🔄 add secrets lifecycle management: https://dotenvx.com/ops\r\nteamcity-mcp v2.2.1\r\n```\r\n\r\nSuppressing stderr, to get just stdout,", "SourceUrl": "https://github.com/Daghis/teamcity-mcp/issues/400", "PublishedAt": "2026-02-18T21:57:35.000Z", "State": "closed", "Comments": 1, "Reporter": "Maintainer", "Rank": "recent", "Extractor": "github_issue" } ], "Observations": [], "ObservationCount": 0, "Related": [ { "Slug": "ssh-policy-gated-remote-access", "Name": "SSH — policy-gated remote access", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/ssh-policy-gated-remote-access" }, { "Slug": "google-drive-mcp", "Name": "Google Drive MCP", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/google-drive-mcp" }, { "Slug": "ignite-ui-theming-mcp-server", "Name": "Ignite UI Theming MCP Server", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/ignite-ui-theming-mcp-server" }, { "Slug": "google-workspace", "Name": "Google Workspace", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/google-workspace" }, { "Slug": "memorix", "Name": "Memorix", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/memorix" }, { "Slug": "zendesk-mcp-server", "Name": "zendesk-mcp-server", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/zendesk-mcp-server" }, { "Slug": "open-zk-kb", "Name": "open-zk-kb", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/open-zk-kb" }, { "Slug": "lunch-money", "Name": "Lunch Money", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/lunch-money" }, { "Slug": "rea", "Name": "REA", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/rea" }, { "Slug": "witness", "Name": "witness", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/witness" }, { "Slug": "labby", "Name": "Labby", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/labby" }, { "Slug": "mcpm", "Name": "mcpm", "Reason": "Also by github.com", "Url": "https://askpod.ai/mcp/mcpm" } ], "Indexable": true, "ContentMarkdown": "# teamcity MCP Server\n\nMCP server exposing JetBrains TeamCity CI/CD workflows to AI coding assistants\n\n**Publisher claimed.** No tool list reported, and Pod has not connected to this server.\n\n## Status\n\nPod 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.\n\n## Connect\n\nPublished as `@daghis/teamcity-mcp` on npm. Runs locally.\n\n## Known issues\n\n**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.\n\n### Most discussed\n\n### refactor(teamcity): unify adapter-based client initialization\n\nParent: #106\n\n## Summary\nRework 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.\n\n## Scope\n- Extend `createAdapterFromTeamCityAPI` to surface the modules and helper methods provided by the expanded `TeamCityAPI`, including the shared axios instance.\n- Update `src/teamcity/index.ts` so `initiali\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/114) · 2025-09-16 · closed · 11 comments\n\n### refactor(teamcity): route build results/list through unified client\n\nParent: #106\n\n## Summary\nEliminate 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.\n\n## Scope\n- Update these modules to call adapter APIs (or the shared `http` instance) instead of creating ad-hoc axios clients:\n - `build-results-manager.ts`\n - `build-list-manager.ts`\n - `build-results-manager` helper methods that fetch artifacts/statistics/changes/dependencies.\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/116) · 2025-09-16 · closed · 8 comments\n\n### refactor(teamcity): migrate build/project managers to adapter\n\nParent: #106\n\n## Summary\nConvert 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.\n\n## Scope\n- Update the following modules to type against `TeamCityClientAdapter` and consume the expanded surface from #113/#114:\n - `build-config-manager.ts`\n - `build-configuration-update-manager.ts`\n - `build-configuration-resolver.ts`\n - `build-confi\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/115) · 2025-09-16 · closed · 7 comments\n\n### Add MCP `annotations` (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) to every tool registration\n\n## Background\n\nGlama'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).\n\nThis is the highest-leverage improvement av\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/467) · 2026-04-23 · closed · 4 comments\n\n### Investigate whether the TeamCity REST API supports chunked downloads via axios streams\n\n## Summary\nSubtask 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.\n\n## Goals\n- Confirm which TeamCity REST endpoints support HTTP streaming or range requests for artifact content.\n- Evaluate client-side requirements (Axios adapters, responseType options, Node.js stream han\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/157) · 2025-09-19 · closed · 4 comments\n\n### Most recent\n\n### Build scriptable REST API coverage matrix (scripts/audit-rest-coverage.ts + docs/rest-coverage.md)\n\n## Background\n\nWe 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.\n\nA 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\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/503) · 2026-05-11 · closed · 1 comment\n\n### Strategic gap-coverage initiative (epic)\n\n## Why this exists\n\nteamcity-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.\n\nThis epic tracks a three-step initiative to make those decisions explicit and data-driven instead of ad-hoc.\n\n## Sub-issues (in execution order)\n\n- [ ] #502 — Commit to\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/501) · 2026-05-11 · closed · 1 comment\n\n### feat: add list_build_artifacts tool for subdirectory browsing\n\n## Problem\n\nThe current artifact tools can list top-level artifacts but cannot browse into subdirectories:\n\n1. `get_build_results` shows directories (e.g. `okd` with size: 0) but doesn't list their children — only top-level entries are returned.\n2. `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.\n3. The TeamCity REST API supports listing subdirectory contents via the `basePath` parameter on\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/490) · 2026-04-28 · closed · outside contributor · 0 comments\n\n### Add targeted sibling-disambiguation only where tool names genuinely collide\n\n## Background\n\nGlama'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.\n\nThis issue covers only those targeted cases — a deliberately narrow scope.\n\n## Goal\n\nFor each of the cases below, add a single short disambiguating clause (≤10 words) explaining when t\n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/471) · 2026-04-23 · closed · 1 comment\n\n### Mutating tools must disclose principal return value and likely failure mode\n\n## Background\n\nFor 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.\n\n## Goal\n\nEvery tool registered with `readOnlyHint: false` ends its description with \n\n[Read the thread](https://github.com/Daghis/teamcity-mcp/issues/470) · 2026-04-23 · closed · 0 comments\n\n### Adopt a single description template across all MCP tools\n\n## Background\n\nTool 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.\n\n## Goal\n\nEvery tool description follows the same skeleton:\n\n> `