Skip to main content
Glama
concavegit

App Store Connect MCP Server

by concavegit

create_app_store_version

Create a new App Store version by specifying platform, version string, and release type to prepare apps for distribution on Apple platforms.

Instructions

Create a new app store version for an app

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appIdYesThe ID of the app
platformYesThe platform for this version
versionStringYesVersion string in format X.Y or X.Y.Z (e.g., '1.0' or '1.0.0')
copyrightNoCopyright text for this version (optional)
releaseTypeNoHow the app should be released
earliestReleaseDateNoEarliest release date in ISO 8601 format (required when releaseType is SCHEDULED)
buildIdNoID of the build to associate with this version (optional)

Implementation Reference

  • Implementation of the createAppStoreVersion handler function that validates inputs, constructs the API request, and calls the App Store Connect API to create a new app store version.
    async createAppStoreVersion(args: {
      appId: string;
      platform: 'IOS' | 'MAC_OS' | 'TV_OS' | 'VISION_OS';
      versionString: string;
      copyright?: string;
      releaseType?: 'MANUAL' | 'AFTER_APPROVAL' | 'SCHEDULED';
      earliestReleaseDate?: string;
      buildId?: string;
    }): Promise<AppStoreVersionResponse> {
      const { 
        appId, 
        platform, 
        versionString, 
        copyright, 
        releaseType, 
        earliestReleaseDate,
        buildId 
      } = args;
      
      validateRequired(args, ['appId', 'platform', 'versionString']);
      
      // Validate version string format
      const versionRegex = /^\d+\.\d+(\.\d+)?$/;
      if (!versionRegex.test(versionString)) {
        throw new Error('Version string must be in format X.Y or X.Y.Z (e.g., 1.0 or 1.0.0)');
      }
      
      // Validate release date if provided
      if (earliestReleaseDate) {
        const date = new Date(earliestReleaseDate);
        if (isNaN(date.getTime())) {
          throw new Error('Invalid release date format. Use ISO 8601 format (e.g., 2024-01-01T00:00:00Z)');
        }
        if (releaseType !== 'SCHEDULED') {
          throw new Error('earliestReleaseDate can only be set when releaseType is SCHEDULED');
        }
      }
      
      const requestData: AppStoreVersionCreateRequest = {
        data: {
          type: 'appStoreVersions',
          attributes: {
            platform,
            versionString,
            ...(copyright && { copyright }),
            ...(releaseType && { releaseType }),
            ...(earliestReleaseDate && { earliestReleaseDate })
          },
          relationships: {
            app: {
              data: {
                type: 'apps',
                id: appId
              }
            },
            ...(buildId && {
              build: {
                data: {
                  type: 'builds',
                  id: buildId
                }
              }
            })
          }
        }
      };
      
      return this.client.post<AppStoreVersionResponse>(
        '/appStoreVersions',
        requestData
      );
    }
  • MCP tool schema definition for 'create_app_store_version', specifying input parameters, descriptions, enums, and required fields.
      name: "create_app_store_version",
      description: "Create a new app store version for an app",
      inputSchema: {
        type: "object",
        properties: {
          appId: {
            type: "string",
            description: "The ID of the app"
          },
          platform: {
            type: "string",
            description: "The platform for this version",
            enum: ["IOS", "MAC_OS", "TV_OS", "VISION_OS"]
          },
          versionString: {
            type: "string",
            description: "Version string in format X.Y or X.Y.Z (e.g., '1.0' or '1.0.0')"
          },
          copyright: {
            type: "string",
            description: "Copyright text for this version (optional)"
          },
          releaseType: {
            type: "string",
            description: "How the app should be released",
            enum: ["MANUAL", "AFTER_APPROVAL", "SCHEDULED"]
          },
          earliestReleaseDate: {
            type: "string",
            description: "Earliest release date in ISO 8601 format (required when releaseType is SCHEDULED)"
          },
          buildId: {
            type: "string",
            description: "ID of the build to associate with this version (optional)"
          }
        },
        required: ["appId", "platform", "versionString"]
      }
    },
  • src/index.ts:1348-1349 (registration)
    Registration and dispatching logic that routes 'create_app_store_version' tool calls to the LocalizationHandlers.createAppStoreVersion method.
    case "create_app_store_version":
      return { toolResult: await this.localizationHandlers.createAppStoreVersion(args as any) };
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 states 'create' which implies a write/mutation operation, but doesn't disclose any behavioral traits such as required permissions, whether the creation is reversible, rate limits, or what happens on success/failure. For a creation tool with zero annotation coverage, this is a significant gap in transparency.

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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration. This is an excellent example of conciseness for a straightforward tool.

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 (7 parameters, creation/mutation operation) and the lack of both annotations and an output schema, the description is insufficiently complete. It doesn't cover behavioral aspects, usage context, or what to expect upon creation. For a mutation tool with no structured safety or output information, the description should provide more guidance to compensate.

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 no parameter-specific information beyond what's already in the input schema, which has 100% description coverage. It doesn't explain relationships between parameters (e.g., that 'earliestReleaseDate' is required only when 'releaseType' is 'SCHEDULED', though this is hinted in the schema). With high schema coverage, the baseline is 3, and the description doesn't add meaningful semantic context.

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 ('create') and resource ('new app store version for an app'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_app_store_versions' or 'update_app_store_version_localization', which would require mentioning it's specifically for creation rather than listing or updating.

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 an existing app or build), exclusions, or how it relates to sibling tools like 'create_bundle_id' or 'list_app_store_versions'. This leaves the agent with insufficient context for proper tool 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