Skip to main content
Glama
Sign In
TeamCity MCP Server

TeamCity MCP Server

by Daghis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

fetch_build_log

Read-onlyIdempotent

Retrieve TeamCity build logs by build ID using line-based pagination, tail mode, or streamed output to a file for large logs.

Instructions

Fetch a build log. Supports line-based pagination and streaming output.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number
tailNoTail mode: return last N lines
buildIdNoBuild ID (TeamCity internal id)
encodingNoResponse encoding: 'text' (default) or 'stream'. 'stream' writes the whole log, or the requested line range, to outputPath; logs can be several GBtext
pageSizeNoLines per page (default 500)
lineCountNoMax lines to return (overrides pageSize)
startLineNo0-based start line (overrides page)
outputPathNoOptional absolute path to write streamed logs; defaults to a temp file when streaming
buildNumberNoHuman build number (e.g., 54). If provided, optionally include buildTypeId to disambiguate.
buildTypeIdNoOptional build type ID to disambiguate buildNumber
minFreeDiskMbNoStreaming only: disk space in MiB that must stay free on the target disk, otherwise the download aborts (default 1024, 0 disables the reserve)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.5
    • changedInput schema / properties / encoding / description
      Previous value: -"Response encoding: 'text' (default) or 'stream'"New value: +"Response encoding: 'text' (default) or 'stream'. 'stream' writes the whole log, or the requested line range, to outputPath; logs can be several GB"
    • addedInput schema / properties / minFreeDiskMb
      Added value: +{
+  "description": "Streaming only: disk space in MiB that must stay free on the target disk, otherwise the download aborts (default 1024, 0 disables the reserve)",
+  "type": "number"
+}
  2. Addedv1.0.2
  3. Removedv1.0.1
  4. Changed2 schema fields changedv1.0.0
    • addedInput schema / properties / encoding
      Added value: +{
+  "default": "text",
+  "description": "Response encoding: 'text' (default) or 'stream'",
+  "enum": [
+    "text",
+    "stream"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / outputPath
      Added value: +{
+  "description": "Optional absolute path to write streamed logs; defaults to a temp file when streaming",
+  "type": "string"
+}
  5. First observed

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that pagination is line-based and that streaming output exists, but omits critical behavior visible only in the schema: that 'stream' writes multi-GB logs to a file path and enforces a disk reserve. With annotations carrying safety, a 3 fits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and followed by capability hints; no filler. However, the terseness leaves out routing and mode-selection guidance that would earn a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 11 parameters and no output schema, yet the description never explains what is returned in text vs stream mode (e.g., that streamed logs go to outputPath) or how tail/page/startLine interact. The rich schema compensates for parameter semantics, but the description is thin for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter, including the streaming/disk-playback semantics, is documented in the schema. The description adds only the high-level notion of line-based pagination, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Fetch a build log') and adds scope cues ('line-based pagination and streaming output'). It doesn't explicitly distinguish itself from siblings like get_build_results or download_build_artifact, so it stops short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings, no prerequisites (buildId vs buildNumber+buildTypeId disambiguation is only in the schema), and no indication of when pagination, tail, or streaming mode should be chosen. Usage is only implied by the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools