Expo Application Services

Expo Application Services MCP server

Find out from your AI assistant why an Expo app's build, workflow run or store submission failed, through Expo Application Services (EAS): job logs by step, Apple's or Google's error text, a credentials audit, fingerprints and update channels. It can also cancel builds and runs, submit an existing build, republish or roll out an update, set the App Store Connect key a bundle id submits with, and dispatch a workflow. dispatch_workflow is the one money tool: your client asks you before each call.

You need an Expo account with an EAS project, and an access token in a file, ideally a robot user's with the Developer role. A dispatch runs a workflow file from the project's GitHub repository, and its build jobs spend build credits on your Expo plan.

What you can ask

• "Why did the last iOS workflow run of @acme/my-app fail?"
• "Does every iOS bundle have a key set for TestFlight submissions, and does any certificate expire in the next 30 days?"
• "Run ios-beta.yml on main and tell me when it finishes."
• "Which fingerprints have updates but no build yet?"
• "Promote the latest update on the staging branch to production."
• "Raise the rollout of the latest production update to 50%."

Install

With Claude Code:

claude mcp add eas -e EXPO_TOKEN_FILE="<path to Expo token file>" -- npx -y @foreverworks/mcp-eas

Claude Desktop (Settings, Developer, Edit Config) and most other clients read the same command as JSON:

{

"mcpServers": { "eas": { "command": "npx", "args": ["-y", "@foreverworks/mcp-eas"], "env": { "EXPO_TOKEN_FILE": " " } } } }

Each runs the published package on Node 22.19 or newer. VS Code and the Claude Desktop bundle ask for each setting as they add the server; leave an optional one empty. Cursor reads each from your environment instead (${env:EXPO_TOKEN_FILE} and so on), so set them before you start Cursor. The commands above set only what is required; Configuration has the rest.

From a clone

git clone https://github.com/foreverworks/mcps.git && cd mcps

npm ci && npm run build claude mcp add eas -e EXPO_TOKEN_FILE=" " -- node "$PWD/servers/eas/dist/index.js"

In a JSON configuration, the command is node and its one argument the full path of servers/eas/dist/index.js. To share one running copy between several clients over HTTP, see docs/deploying.md.

Configuration

validate_workflow reads a file given by path from MCP_FILE_ROOTS. That and the other variables every server shares (transport, limits, what tools may do) are in docs/configuration.md.

Getting a robot user's token

Make a robot user for the server: it belongs to the account rather than to a person, its role bounds what the server can do, and you can revoke it on its own. At expo.dev, in the account's settings:

1. Open Robots and Create robot, with a name that says where it runs. Give it the Developer role, which is enough for every tool here (build, submit, credentials; no billing, no members). Viewer limits the server to the reads: every write then answers forbidden.
2. On the robot, Create access token. Expo shows it once: save it in a file readable only by you (chmod 600).
3. Point EXPO_TOKEN_FILE at that file.

Expo access tokens do not expire; to rotate one, replace the file.

First run

1. Ask your assistant to run the EAS health check. It says whether the token works, as which actor (ideally a robot user), and the accounts and projects it sees.
2. If it sees several projects, set EAS_PROJECT, or name the project in each request (list_projects gives the names).
3. Ask for a credentials audit (audit_credentials) to see what is missing or about to expire.

Tools

read changes nothing; write changes something at EAS or in a store without spending build credits; money spends EAS build credits, and your client asks you before each call.

Money

The only way this server starts a build is a workflow run, so dispatch_workflow is the one money tool. It is marked so in tools/list, and your client asks you to approve each call (Claude Code does, in every permission mode). Before the call, the server reads the workflow file at that ref from EAS (which runs nothing), and the run starts that revision of the file, so it runs those jobs even if the branch moves in between. With MCP_CONFIRM=elicit the server asks you itself instead, in one line naming each build job's platform and profile:

eas: Run EAS workflow ios-beta.yml of @acme/my-app at main: builds ios preview (if its condition holds); may spend EAS build credits.

The line names no commit: EAS keys a revision by its content and reports the commit where it first saw that content, not where the ref points now. A file without build jobs says it spends no build credits.

The other changes spend nothing, so they are write, though a republish or a rollout reaches a branch's devices at their next launch, production included (each answer names the production channels it reached), and another republish undoes it.

submit_build and republish_update take an id the model copies, and a miscopied one would ship something else unnoticed. So each answer says what shipped (a build's platform, profile, app version, build number and commit; a group's project, source branch, commit and message), and each checks what you expect before sending: expect_version and expect_build_number for a build, expect_commit (a prefix of 7 or more characters) for a group. A group from another project is always refused.

Troubleshooting

`config`: "neither EXPO_TOKEN_FILE nor EXPO_TOKEN is set". Give the server a token (Getting a robot user's token).

`auth`. EAS refused the token: the robot or its token was deleted or revoked. Check them at expo.dev (account settings, Robots) and replace the token file; it is read again on the next call.

`forbidden`. The robot lacks the permission: writes need the Developer role on the project's account. Change its role at expo.dev (account settings, Members).

`not_found`. Check the id or name: list_projects, list_builds, list_workflow_runs and list_submissions give t