Labsco
MCP SERVER · OFFICIAL PROJECT

Appcircle MCP Server

by appcircleio

Drive Appcircle's mobile CI and store publishing from the agent — build profiles and workflows, commits and build logs, trigger or cancel a build, and run a publish flow to the store.

Mobile & App Store ReleaseVerified
Summary
Four tools open their own description with SIDE EFFECT, which is the cheapest possible way to tell an agent which calls it should stop and ask about.

A build pipeline surface is mostly reads with a few operations that cost money and start machines. Labelling those inline means a model does not have to infer intent from a verb — trigger_build could plausibly be a dry run, and the description settles it before the call rather than after. The metadata lock check is the other detail that shows real familiarity: store metadata being locked mid-release is a normal state and an integration that does not check it produces a confusing failure at the worst moment. Step-scoped logs on both build and publish is the practical touch — mobile build output is enormous and unscoped retrieval is unusable from a chat client.

What it is

An Appcircle client covering the mobile build and release pipeline end to end: build profiles with their configurations and workflows, commit history, build status and logs, variable groups, enterprise store and publish profiles, store metadata, and the publish flow itself.

What you get
  • Every write tool announces itself — trigger_build, cancel_build, start_publish and stop_publish each open their description with SIDE EFFECT and say plainly that this is a write action.
  • Builds are inspectable before and after: profiles, their configurations, their workflows, and a single workflow's detail.
  • Commits by branch, a single commit by UUID or git SHA, and the most recent commit on a branch — three lookups because those are three different questions.
  • get_build_logs can be scoped to a single step rather than returning the whole run, which for a mobile build is the difference between a readable answer and a wall.
  • The publish half mirrors it: publish profiles by platform, the flows configured on one, the run details for an app version, and step-scoped publish logs.
  • Store metadata is covered properly — listing metadata per app version, the available locales, Microsoft Intune metadata, and whether the metadata is currently locked for editing.
  • get_build_history_report returns the history optionally filtered by date range, which is the reporting view rather than the per-build one.
Requirements

APPCIRCLE_ACCESS_TOKEN, and UV_PYTHON since it launches through uv.