Skip to main content
Glama
concavegit

App Store Connect MCP Server

by concavegit

list_build_runs

Retrieve build run history for a CI workflow in App Store Connect, including commit details, execution status, and filtering options.

Instructions

List build runs for a specific workflow/CI product, including git commit information

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ciProductIdYesThe ID of the CI product (workflow) to list build runs for
limitNoMaximum number of build runs to return (default: 100, max: 200)
sortNoSort order for the results
filterNo
includeNoRelated resources to include in the response
fieldsNo

Implementation Reference

  • Core handler function that executes the tool logic: fetches list of build runs for a given CI product (workflow) ID from App Store Connect API, applying filters, sorting, fields, and includes.
    async listBuildRuns(args: {
      ciProductId: string;
      limit?: number;
      sort?: CiBuildRunSortOptions;
      filter?: CiBuildRunFilters;
      fields?: {
        ciBuildRuns?: CiBuildRunFieldOptions[];
      };
      include?: CiBuildRunIncludeOptions[];
    }): Promise<CiBuildRunsResponse> {
      const { ciProductId, limit = 100, sort, filter, fields, include } = args;
      
      const params: Record<string, any> = {
        limit: sanitizeLimit(limit)
      };
    
      if (sort) {
        params.sort = sort;
      }
    
      if (include?.length) {
        params.include = include.join(',');
      }
    
      Object.assign(params, buildFilterParams(filter));
      Object.assign(params, buildFieldParams(fields));
    
      return this.client.get<CiBuildRunsResponse>(`/ciProducts/${ciProductId}/buildRuns`, params);
    }
  • MCP tool schema definition specifying the input parameters, validation, and description for the list_build_runs tool.
      name: "list_build_runs",
      description: "List build runs for a specific workflow/CI product, including git commit information",
      inputSchema: {
        type: "object",
        properties: {
          ciProductId: {
            type: "string",
            description: "The ID of the CI product (workflow) to list build runs for"
          },
          limit: {
            type: "number",
            description: "Maximum number of build runs to return (default: 100, max: 200)",
            minimum: 1,
            maximum: 200
          },
          sort: {
            type: "string",
            description: "Sort order for the results",
            enum: ["number", "-number", "createdDate", "-createdDate", "startedDate", "-startedDate", "finishedDate", "-finishedDate"]
          },
          filter: {
            type: "object",
            properties: {
              number: {
                type: "number",
                description: "Filter by build run number"
              },
              isPullRequestBuild: {
                type: "boolean",
                description: "Filter by whether it's a pull request build"
              },
              executionProgress: {
                type: "string",
                enum: ["PENDING", "RUNNING", "COMPLETE"],
                description: "Filter by execution progress"
              },
              completionStatus: {
                type: "string",
                enum: ["SUCCEEDED", "FAILED", "ERRORED", "CANCELED", "SKIPPED"],
                description: "Filter by completion status"
              },
              startReason: {
                type: "string",
                enum: ["MANUAL", "SCM_CHANGE", "PULL_REQUEST_UPDATE", "SCHEDULED"],
                description: "Filter by start reason"
              }
            }
          },
          include: {
            type: "array",
            items: {
              type: "string",
              enum: ["builds", "workflow", "product", "sourceBranchOrTag", "destinationBranch", "pullRequest"]
            },
            description: "Related resources to include in the response"
          },
          fields: {
            type: "object",
            properties: {
              ciBuildRuns: {
                type: "array",
                items: {
                  type: "string",
                  enum: ["number", "createdDate", "startedDate", "finishedDate", "sourceCommit", "destinationCommit", "isPullRequestBuild", "issueCounts", "executionProgress", "completionStatus", "startReason", "cancelReason"]
                },
                description: "Fields to include for each build run"
              }
            }
          }
        },
        required: ["ciProductId"]
      }
    },
  • src/index.ts:1427-1429 (registration)
    Registration of the tool in the MCP server request handler: dispatches calls to 'list_build_runs' to the workflowHandlers.listBuildRuns method.
    case "list_build_runs":
      const buildRunsData = await this.workflowHandlers.listBuildRuns(args as any);
      return formatResponse(buildRunsData);
  • TypeScript type definitions for the build runs response, filters, sort options, field options, and include options used by the handler and reflected in the tool schema.
    export interface CiBuildRunsResponse {
      data: CiBuildRun[];
      included?: Array<{
        id: string;
        type: "builds" | "ciWorkflows" | "ciProducts" | "scmGitReferences" | "scmPullRequests";
        attributes: any;
      }>;
      links?: {
        self: string;
        first?: string;
        next?: string;
      };
      meta?: {
        paging: {
          total: number;
          limit: number;
        };
      };
    }
    
    export interface CiBuildRunFilters {
      number?: number;
      createdDate?: string;
      startedDate?: string;
      finishedDate?: string;
      isPullRequestBuild?: boolean;
      executionProgress?: "PENDING" | "RUNNING" | "COMPLETE";
      completionStatus?: "SUCCEEDED" | "FAILED" | "ERRORED" | "CANCELED" | "SKIPPED";
      startReason?: "MANUAL" | "SCM_CHANGE" | "PULL_REQUEST_UPDATE" | "SCHEDULED";
      cancelReason?: "AUTOMATICALLY_BY_NEWER_BUILD" | "MANUALLY_BY_USER";
    }
    
    export type CiBuildRunSortOptions = 
      | "number" | "-number"
      | "createdDate" | "-createdDate"
      | "startedDate" | "-startedDate"
      | "finishedDate" | "-finishedDate";
    
    export type CiBuildRunFieldOptions = 
      | "number"
      | "createdDate"
      | "startedDate"
      | "finishedDate"
      | "sourceCommit"
      | "destinationCommit"
      | "isPullRequestBuild"
      | "issueCounts"
      | "executionProgress"
      | "completionStatus"
      | "startReason"
      | "cancelReason";
    
    export type CiBuildRunIncludeOptions =
      | "builds"
      | "workflow"
      | "product"
      | "sourceBranchOrTag"
      | "destinationBranch"
      | "pullRequest";
  • Re-exports utility functions like sanitizeLimit, buildFilterParams, buildFieldParams used in the handler for parameter processing.
    export * from './validation.js';
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool lists build runs 'including git commit information', which hints at read-only behavior and output content. However, it fails to disclose critical traits such as pagination (implied by 'limit' parameter but not explained), rate limits, authentication requirements, error handling, or whether it's a safe read operation. For a tool with 6 parameters and no annotations, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('List build runs') and key output details ('including git commit information'), with zero redundancy or fluff. Every part of the sentence earns its place by conveying essential information.

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

Completeness2/5

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

Given the tool's complexity (6 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), output format (beyond mentioning git commit info), and usage context. Without annotations or an output schema, the description should provide more guidance on what to expect when invoking the tool, but it falls short, leaving the agent with insufficient context for reliable use.

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?

The description adds minimal semantic context beyond the input schema. It implies that parameters relate to filtering and including git commit data, but doesn't elaborate on how 'ciProductId' maps to workflows or what 'git commit information' entails. With 67% schema description coverage (4 out of 6 parameters have descriptions in the schema), the baseline is 3, as the schema does most of the heavy lifting. The description doesn't compensate for the 33% coverage gap (e.g., 'fields' object details are only in the schema).

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?

The description clearly states the action ('List') and resource ('build runs for a specific workflow/CI product'), including the scope of information returned ('including git commit information'). It distinguishes itself from siblings like 'list_ci_build_actions' or 'list_workflows' by focusing on build runs rather than actions or workflows themselves. However, it doesn't explicitly differentiate from 'list_ci_test_results' or 'list_ci_issues', which might be related but not identical.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid ciProductId), exclusions, or comparisons to sibling tools like 'list_ci_build_actions' or 'list_workflows'. The agent must infer usage from the tool name and parameters alone, which is insufficient for optimal selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/concavegit/app-store-connect-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server