# Expo Application Services (npm · @foreverworks/mcp-eas)

Find out why an Expo build, workflow run or store submission failed, and roll out updates.

- Trust score: 79/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@foreverworks/mcp-eas`: 79/100 (this document), [markdown](https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas.md), [page](https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas)

## Channel facts

- Registry: `npm`
- Package: `@foreverworks/mcp-eas`
- Version: `0.1.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 99/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 7 of 24 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to foreverworks/mcps).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 1 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 3969 tokens (~172/item across 23 items; 23 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 88% of tool parameters carry a description.
  - Structured output schemas are declared (35% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 23 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 24 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the Expo Application Services MCP server?

Expo Application Services runs locally as an npm package, launched with npx -y @foreverworks/mcp-eas. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add com-foreverworks-eas -- npx -y @foreverworks/mcp-eas
```

### Cursor

```json
{
  "mcpServers": {
    "com-foreverworks-eas": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-eas"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-foreverworks-eas": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-eas"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add com-foreverworks-eas -- npx -y @foreverworks/mcp-eas
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-foreverworks-eas": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@foreverworks/mcp-eas"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-foreverworks-eas --command npx --arg -y --arg @foreverworks/mcp-eas
```

### Hermes

```yaml
mcp_servers:
  com-foreverworks-eas:
    command: "npx"
    args: ["-y", "@foreverworks/mcp-eas"]
```

### Netclaw

```json
{
  "McpServers": {
    "com-foreverworks-eas": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@foreverworks/mcp-eas"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-foreverworks-eas -t stdio -c npx -a -y @foreverworks/mcp-eas
```

### Other

```json
{
  "mcpServers": {
    "com-foreverworks-eas": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-eas"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 79, +11)

- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.89

### 2026-11-03 (score 68)

First indexed and scored.

## MCP tools (23)

### `audit_credentials` (~180 tokens)

Audit credentials

Per bundle id (iOS) and package (Android) of a project: the distribution certificate and provisioning profile with their expiry, the App Store Connect API key for submissions, the push key, the upload keystore's fingerprints and the Google service account for submissions, and in words what is missing, expired or expiring within 30 days. Every identifier the project has credentials for or has built is covered, so one built without credentials shows up. No secret is ever read.

Input parameters:

- `identifier` (string): One bundle id or package. Default: every one the project has credentials for or has built.
- `platform` (string)
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

### `cancel_build` (~44 tokens)

Cancel build

Cancel a build that is queued or running. EAS refuses one that has already ended, and says so; nothing else changes.

Input parameters:

- `build` (string, required): The build id.

### `cancel_workflow_run` (~42 tokens)

Cancel workflow run

Cancel a workflow run that has not ended, with its running jobs (a build in progress stops spending).

Input parameters:

- `run` (string, required): The workflow run id.

### `dispatch_workflow` (~235 tokens)

Dispatch workflow

Run an EAS workflow file at a git ref the project's GitHub repository already has. EAS reads the file and the code from GitHub; nothing local is uploaded. A build job spends EAS build credits; the summary line names the project, the file, the ref and each build job's platform and profile. Answers with the new run; follow it with get_workflow_run. Moves money or makes a legal document: the client asks the user to approve each call.

Input parameters:

- `git_ref` (string, required): A ref the project's GitHub repository already has: a branch ("main"), "refs/heads/<branch>", "refs/tags/<tag>" or a commit hash.
- `inputs` (object): The workflow_dispatch inputs the file declares, by name.
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).
- `workflow` (string, required): The workflow file name, e.g. "ios-build.yml" (the extension may be left out).

### `get_build` (~114 tokens)

Get build

One build: its artifacts (the .ipa/.aab URL), fingerprint, runtime version, channel, timings and error. A build that ERRORED also carries failedStep, the step that failed and the line that says why, read from its log; steps lists them all.

Input parameters:

- `build` (string, required): The build id.
- `lines` (integer): How many of a step's last log lines to include (0: none).
- `steps` (boolean): Also list every step of the log with its result.

### `get_job_logs` (~114 tokens)

Get job logs

A workflow job's log, by step: every step with its result and size, and the last lines of one step (the failed one by default). What eas workflow:logs --all-steps prints, without the noise.

Input parameters:

- `job` (string, required): The workflow job id (get_workflow_run lists them).
- `lines` (integer): How many of the step's last lines.
- `step` (string): A step's name, or part of it. Default: the failed step, else the last.

### `get_submission` (~96 tokens)

Get submission

One submission with Apple's or Google's error text; one that ERRORED also carries failedStep from its log (its own, or the workflow job's that made it); steps lists every step.

Input parameters:

- `lines` (integer): How many of a step's last log lines to include (0: none).
- `steps` (boolean): Also list every step of the log with its result.
- `submission` (string, required): The submission id.

### `get_workflow_run` (~121 tokens)

Get workflow run

One workflow run with its jobs: each job's type, status and outputs (build_id, fingerprint hashes, app_build_version...) and artifacts. When it failed: reason in one line, and failures per job (the job's own error, which for an App Store upload is Apple's text, else its failed step and the line that says why); lines adds each failed step's tail.

Input parameters:

- `lines` (integer): How many of a step's last log lines to include (0: none).
- `run` (string, required): The workflow run id.

### `health` (~49 tokens)

Health

Check that the Expo access token is present and accepted: which actor it is (a robot user, ideally), its accounts and the projects it sees. Reads only. Run this before concluding the server is broken.

### `list_builds` (~213 tokens)

List builds

A project's builds, newest first, filtered by platform, status, profile, bundle id or package, commit or fingerprint. Each says its status, profile, identifier, version and build number, commit, fingerprint, runtime, who started it and its error.

Input parameters:

- `app_identifier` (string): A bundle id or package, e.g. com.example.app.dev.
- `commit` (string): The full git commit hash the build was made from.
- `fingerprint` (string): Builds carrying this fingerprint hash.
- `limit` (integer)
- `offset` (integer): Skip this many, newest first: nextOffset from the previous call.
- `platform` (string)
- `profile` (string): The eas.json build profile, e.g. "production".
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).
- `status` (string)

Output parameters:

- `builds` (array)
- `nextOffset` (integer)
- `project` (string)

### `list_fingerprints` (~133 tokens)

List fingerprints

A project's fingerprints (the hash of its native side), newest first, or one by hash: how many builds and updates carry each, and the latest of them. Answers whether a build exists for a native state, the question a fingerprint-gated workflow asks.

Input parameters:

- `hash` (string): One fingerprint hash (a build's or a fingerprint job's output).
- `limit` (integer)
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

Output parameters:

- `fingerprints` (array)
- `project` (string)

### `list_projects` (~54 tokens)

List projects

The EAS projects this token can see, per account, with their full names (@account/slug) and ids: what every other tool's project argument takes. A tool may leave project out when the token sees only one.

Output parameters:

- `accounts` (array)
- `actor` (object)
- `defaultProject` (string)

### `list_submissions` (~157 tokens)

List submissions

A project's App Store Connect and Google Play submissions, newest first: status, the build (identifier, version, build number), the ASC app or Play track, the workflow job that made it, and error: Apple's or Google's own text (for a workflow's submission it lives on the job, which this reads).

Input parameters:

- `limit` (integer)
- `offset` (integer): Skip this many, newest first: nextOffset from the previous call.
- `platform` (string)
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).
- `status` (string)

Output parameters:

- `nextOffset` (integer)
- `project` (string)
- `submissions` (array)

### `list_updates` (~90 tokens)

List updates

A project's EAS Update channels with the branches they serve (production ones marked), and per branch the latest update for each platform and runtime version: what a device on that runtime downloads next.

Input parameters:

- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

Output parameters:

- `branches` (array)
- `channels` (array)
- `project` (string)

### `list_workflow_runs` (~250 tokens)

List workflow runs

A project's workflow runs, newest first, optionally of one workflow file, status or ref: status, ref, commit, trigger (a GitHub push, a schedule, a dispatch) and who. A FAILURE run carries reason: the failed job, its failed step and the line that says why, read from the job's log (e.g. "submit_ios > Prepare credentials: eas-cli failed to resolve submission config ...").

Input parameters:

- `cursor` (string): nextCursor from the previous call, to read on.
- `git_ref` (string): Only runs requested at this ref, e.g. "refs/heads/main".
- `limit` (integer)
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).
- `reasons` (boolean): Read each FAILURE run's failed jobs' logs for its one-line reason (a request or two per failed run).
- `status` (string)
- `workflow` (string): The workflow file name, e.g. "ios-build.yml" (the extension may be left out).

Output parameters:

- `nextCursor` (string)
- `project` (string)
- `runs` (array)

### `list_workflows` (~83 tokens)

List workflows

A project's EAS workflow files (.eas/workflows/*.yml), by file name: what list_workflow_runs and dispatch_workflow take.

Input parameters:

- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

Output parameters:

- `project` (string)
- `workflows` (array)

### `republish_update` (~263 tokens)

Republish update

Put an existing update group on a branch again, as eas update:republish does: roll a branch back to an earlier group, or promote a group from one branch to another. Nothing is uploaded. Refuses a group of another project, a code-signed group or one in a rollout, and with expect_commit a group published from another commit. Answers with where the group came from (its branch, commit and message) and the new group.

Input parameters:

- `branch` (string, required): The update branch to republish onto, e.g. "production".
- `expect_commit` (string): The commit the group must have been published from (a hash, or a prefix of at least 7 characters). Checked before anything is published.
- `group` (string, required): The update group to put on the branch again (list_updates gives groups).
- `message` (string): The new update's message. Default: names the group republished.
- `platform` (string): Only this platform's update of the group. Default: every platform in it.
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

### `revert_rollout` (~194 tokens)

Revert rollout

End an update group's rollout by sending every device on its branch and runtime back to the update before it, as eas update:revert-update-rollout does: that update's group is published on the branch again, ending the rollout; nothing is deleted or uploaded. Refuses a rollout something newer already ended, and one with no update before it (the app's embedded update; revert that with eas-cli in the project). Answers with the groups republished and the production channels.

Input parameters:

- `group` (string, required): The update group in the rollout (list_updates shows each branch's latest groups with their rolloutPercentage).
- `platform` (string): Only this platform's rollout. Default: every platform in it.
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

### `set_rollout` (~204 tokens)

Set rollout

Raise an update group's rollout to a percentage of the devices on its branch and runtime, as eas update:edit does; 100 rolls it out to every device and ends the rollout. A rollout only grows (revert_rollout takes it back); setting what it already is changes nothing. Answers with the percentage before and after, and the production channels that serve the branch.

Input parameters:

- `group` (string, required): The update group in the rollout (list_updates shows each branch's latest groups with their rolloutPercentage).
- `percentage` (integer, required): The share of devices to get it, higher than now; 100 rolls it out to every device.
- `platform` (string): Only this platform's update of the group. Default: every platform in the rollout.
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

### `set_submit_key` (~204 tokens)

Set submit key

Set (or clear) the App Store Connect API key EAS uses to submit one iOS bundle id, as eas credentials does. Without one, eas submit and a workflow's submit job fail at Prepare credentials. Answers with the key before and the bundle's audit after.

Input parameters:

- `bundle_id` (string, required): The iOS bundle id whose submissions use the key, e.g. com.example.app.dev.
- `clear` (boolean): Remove the key set for submissions instead (eas submit for this bundle then fails until one is set).
- `key` (string): The App Store Connect API key, by its 10-character Apple key id (e.g. "ABCDE12345") or its EAS id; the account must already hold it.
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).

### `submit_build` (~363 tokens)

Submit build

Submit an existing FINISHED build: iOS to App Store Connect (TestFlight), Android to a Google Play track. It uses what EAS holds for the build's own bundle id or package (the ASC key or Google service account set for submissions, as audit_credentials shows it), so it fails before scheduling anything when that is missing. Spends no build credits. Give expect_version or expect_build_number when you know what should ship: a build that differs is refused. Answers with the build as submitted (platform, profile, app version, build number, commit) and the submission; follow it with get_submission.

Input parameters:

- `asc_app_id` (string): iOS: the App Store Connect app id. Default: the app App Store Connect has for the build's bundle id, asked through its key.
- `build` (string, required): The id of a FINISHED build (list_builds).
- `expect_build_number` (string): The build number the build must have (iOS CFBundleVersion, Android versionCode), e.g. "42". Checked the same way.
- `expect_version` (string): The app version the build must have, e.g. "1.4.2". Checked before anything is submitted, so a wrongly copied build id fails instead of shipping another build.
- `groups` (array): iOS: TestFlight groups to add the build to.
- `release_status` (string): Android: the release status on the track.
- `rollout` (number): Android: the staged rollout fraction, with release_status in_progress.
- `track` (string): Android: the Google Play track. Default "internal".
- `what_to_test` (string): iOS: TestFlight's What to Test; Android: the release notes.

### `validate_workflow` (~425 tokens)

Validate workflow

Check an EAS workflow file before it runs, the way eas workflow:validate does, without a checkout: the file as the project's repository has it at a ref (workflow and git_ref; EAS reads it from GitHub, as a dispatch would), or a file (path). Answers valid, the issues (YAML that does not parse, a needs: naming no job, and every problem EAS's own validator names, field by field), the jobs, and the build jobs a dispatch would spend credits on. Runs nothing, spends nothing. Never type or paste a file's base64 yourself: a retyped file can arrive changed. Give the path of a file in your workspace folders (the roots this client shares; without them /workdir), or have a script that read the file send content_base64 with its sha256.

Input parameters:

- `content_base64` (string): Instead of path: the file's bytes as standard base64, only as a script that read the file wrote them, never typed. Needs sha256.
- `git_ref` (string): With workflow: a branch ("main"), "refs/heads/<branch>", "refs/tags/<tag>" or a commit hash the repository already has.
- `path` (string): Instead of workflow and git_ref, a workflow file: a file in your workspace folders (the roots this client shares with the server; without them /workdir); a bare name is taken from the first. Links ar…
- `project` (string): The project: "@account/slug" (e.g. "@acme/my-app"), its slug, or its id. Leave it out when the token sees one project (list_projects).
- `sha256` (string): Hex SHA-256 of the source file, as sha256sum prints it. Required with content_base64, checked with path.
- `workflow` (string): With git_ref: the workflow file as the repository has it there, e.g. "ios-build.yml"; a file EAS has not run yet works too.

Output parameters:

- `builds` (array)
- `issues` (array)
- `jobs` (array)
- `project` (string)
- `source`
- `valid` (boolean)

### `wait_for_run` (~207 tokens)

Wait for a run or a build

Wait until a workflow run or a build ends (give run or build), looking every 15 s, and answer as get_workflow_run or get_build would then: the outcome and, when it failed, the reason. While it waits, a client that asks for progress hears where it stands (jobs done, the job running). A run that waits for someone's approval, or one still going after minutes, answers done: false with its state; cancelling the call only stops the waiting, never the run.

Input parameters:

- `build` (string): A build id, from list_builds or a run's build job.
- `lines` (integer): How many of a step's last log lines to include (0: none).
- `minutes` (integer): How long to wait at most (a request over HTTP is cut at 15 minutes by default); call again to keep waiting.
- `run` (string): A workflow run id, from dispatch_workflow or list_workflow_runs.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas#diagnostics

## Score history

- 2026-11-05: 79
- 2026-11-04: 79
- 2026-11-03: 68

## Common questions

### What is the Expo Application Services MCP server?

Expo Application Services is an MCP server listed in the public MCP registry as com.foreverworks/eas. Find out why an Expo build, workflow run or store submission failed, and roll out updates. This page covers its npm package (@foreverworks/mcp-eas).

### Is the Expo Application Services MCP server safe to use?

Expo Application Services scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Expo Application Services MCP server expose?

Expo Application Services exposes 23 tools: audit_credentials, cancel_build, cancel_workflow_run, dispatch_workflow, get_build, and 18 more. Their descriptions and schemas cost roughly 3,835 tokens of context every time the server is loaded.

### Is the Expo Application Services MCP server still maintained?

Expo Application Services is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Expo Application Services MCP server under?

Expo Application Services declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

### What did VerifyMCP test on the Expo Application Services MCP server?

VerifyMCP ran 15 checks on Expo Application Services, covering Malware scan, Known CVEs, Install scripts, Dependency health and 11 more. One item could not be completed, a gap on our side rather than a finding about Expo Application Services: Stability. One category scores 0 for that reason, because we only credit what we can confirm. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- npm package: https://www.npmjs.com/package/@foreverworks/mcp-eas
- Socket report: https://socket.dev/npm/package/@foreverworks/mcp-eas
- Repository: https://github.com/foreverworks/mcps
- Website: https://foreverworks.github.io/mcps/servers/eas/
- Changelog RSS feed: https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas.json
- HTML version of this page: https://verifymcp.io/servers/com-foreverworks-eas/foreverworks-mcp-eas