MCP Servers for Expo
Expo's value comes from managing the native layer for you, and almost every agent failure here is an agent stepping around that management because older React Native advice told it to. The agent needs to know the SDK version, whether the project uses continuous native generation or has committed native directories, and whether the target runtime is Expo Go or a development build. Package versions are pinned to the SDK, so installing with the wrong tool is enough to break a build that was previously fine.
Wiring MCP into a Expo project
- → Prioritise GitHub and crash reporting servers, since most Expo problems are library compatibility rather than local code.
- → Scope the filesystem server to app/, components/, and the config files so generated native output stays out of context.
- → Commit .mcp.json alongside app.config.js so agent tooling and app configuration stay in sync across the team.
Servers worth adding
Filesystem MCP server
Scoped read and write access to the project.
Whether ios/ and android/ are present and gitignored is the single fact that decides how every native question should be answered.
Git MCP server
History, diffs, and blame.
SDK upgrades touch many files at once, and the diff is the quickest way for the agent to see which upgrade this project is mid-way through.
GitHub MCP server
Reads issues, releases, and pull requests.
Config plugin compatibility with a given SDK version is usually only stated in a library's release notes or open issues.
Sentry MCP server
Pulls crash reports and traces.
Over-the-air update rollouts can break a subset of installs, and crash grouping by release is how you spot which update did it.
Rule these out for Expo
These are the failures that repeat across sessions, so each one belongs in .mcp.json.
Editing ios/ and android/ in a prebuild managed project
Asked to change an app permission or a native setting, an agent opens Info.plist or AndroidManifest.xml and edits it directly. If the project uses continuous native generation, the next prebuild regenerates those directories and silently discards the change, so the bug reappears after a clean build. Add to your rules file: 'Native configuration is expressed in app.json or app.config.js, through config plugins. Never edit files under ios/ or android/, and never commit them.'
Using npm install for SDK-managed packages
Agents run npm install expo-camera and get the latest release, which is frequently incompatible with the installed SDK and fails at build time with an error that points nowhere useful. The expo install command resolves the version the SDK actually expects. Write: 'Install Expo packages with npx expo install, never npm or yarn add. Run npx expo install --check after any dependency change and fix what it reports.'
Recommending react-native link and manual native setup
Library READMEs and older training data still describe react-native link, manual Podfile edits, and MainApplication.java registration. None of that applies here, and following it in a managed project produces changes that either fail or get regenerated away. Add: 'Native setup is done with config plugins. react-native link does not exist, and manual Podfile or Gradle instructions from a library README must be translated into a plugin or flagged rather than applied.'
Assuming Expo Go can run any native module
Agents suggest testing in Expo Go after adding a library with custom native code, which Expo Go cannot load because its native binary is fixed. The resulting error looks like a broken install and sends the agent debugging JavaScript. State the runtime: 'This project runs on a development build, not Expo Go. Any library with custom native code requires a new development build before it can be tested.'
Mixing manual navigators with the Expo Router file tree
In an Expo Router project, agents add a manually constructed stack navigator inside a screen, or create a route file without the _layout.tsx that gives it a parent, producing routes that render outside the intended navigation hierarchy. Add: 'Routing is file based under app/. Screens are files, groups use parentheses, and every directory that needs a navigator has a _layout.tsx. Do not construct navigators by hand.'
Treating app config extra values as private
Agents put an API key into the extra block of app.json or into a non-public EAS environment variable and treat it as a secret, but anything bundled into the app ships to every device and can be extracted. Only build-time credentials that never enter the bundle are actually protected. Write: 'Nothing in app config or in the JavaScript bundle is secret. Signing credentials and service tokens live in EAS secrets, and any key that must stay private is used from your backend, never from the app.'