Skip to main content
Glama
seungmanchoi

expo-app-scaffold-mcp

by seungmanchoi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

expo-app-scaffold-mcp

Expo + React Native 앱을 FSD(Feature-Sliced Design) 템플릿 기반으로 빠르게 생성하는 MCP(Model Context Protocol) 서버입니다.

기능

  • scaffold_app - 템플릿에서 새 Expo 앱 프로젝트 생성

  • setup_store_config - App Store / Google Play 배포 설정 구성

  • list_apps - ~/works/ 아래의 모든 Expo 앱 목록 조회

Related MCP server: Expo MCP Server

기술 스택 (템플릿 기준)

  • Expo SDK 54 + React Native

  • expo-router (파일 기반 라우팅)

  • NativeWind v4 (Tailwind CSS)

  • Feature-Sliced Design 아키텍처

  • TypeScript strict 모드

  • @tanstack/react-query, react-hook-form, zustand

  • expo-secure-store, lottie-react-native, dayjs, axios

설치 및 빌드

cd /Users/seungmanchoi/works/expo-app-scaffold-mcp
npm install
npm run build

Claude Code에 MCP 서버 등록

~/.claude/settings.json 파일에 아래 내용을 추가합니다.

{
  "mcpServers": {
    "expo-app-scaffold": {
      "command": "node",
      "args": ["/Users/seungmanchoi/works/expo-app-scaffold-mcp/dist/index.js"]
    }
  }
}

사용 가능한 도구

scaffold_app

새 Expo 앱을 FSD 템플릿에서 스캐폴딩합니다.

파라미터:

이름

타입

필수

설명

app_name

string

필수

앱 표시 이름 (예: "나의 멋진 앱")

slug

string

필수

URL 안전 슬러그 (예: "my-cool-app")

bundle_id

string

선택

번들 식별자. 기본값: com.seungmanchoi.{slug 하이픈 제거}

theme_color

string

선택

테마 색상 hex 코드. 기본값: "#6366f1"

description

string

선택

앱 설명. package.json에 추가됨

languages

string[]

선택

지원 언어 목록. 기본값: ["ko", "en"]

예시:

scaffold_app 도구를 사용해서 새 앱을 만들어줘:
- 앱 이름: 칼로리 트래커
- 슬러그: calorie-tracker
- 언어: 한국어, 영어, 일본어

동작:

  1. /Users/seungmanchoi/works/react-native-fsd-template을 ~/works/{slug}/로 복사

  2. app.json 업데이트: name, slug, bundleIdentifier, package, scheme

  3. package.json 업데이트: name, description

  4. eas.json 업데이트: production API URL

  5. i18n 로케일 파일 생성: src/shared/config/i18n/

  6. git 저장소 초기화 및 초기 커밋

setup_store_config

앱 스토어 및 구글 플레이 배포 설정을 구성합니다.

파라미터:

이름

타입

필수

설명

project_path

string

필수

프로젝트 경로 (절대 경로)

platforms

string[]

필수

플랫폼 목록: ["ios", "android"] 또는 개별

admob_ios_id

string

선택

AdMob iOS 앱 ID

admob_android_id

string

선택

AdMob Android 앱 ID

예시:

setup_store_config 도구로 /Users/seungmanchoi/works/calorie-tracker 앱의
iOS와 Android 배포 설정을 해줘

동작:

  1. eas.json submit 섹션에 iOS/Android API 키 정보 추가

  2. fastlane/ 디렉토리 생성: Appfile, Fastfile

  3. ~/works/common/ 경로의 API 키 파일 참조 설정

  4. AdMob ID가 제공된 경우 app.json에 플러그인 설정 추가

list_apps

~/works/ 디렉토리에서 Expo 앱 목록을 조회합니다.

파라미터: 없음

예시:

list_apps 도구로 내 Expo 앱 목록을 보여줘

반환 정보: 각 앱의 이름, 슬러그, 번들 ID, 버전, 경로

프로젝트 구조

expo-app-scaffold-mcp/
├── package.json
├── tsconfig.json
├── src/
│   ├── index.ts                    # MCP 서버 진입점 (stdio transport)
│   ├── tools/
│   │   ├── scaffold-app.ts         # scaffold_app 도구 구현
│   │   ├── setup-store-config.ts   # setup_store_config 도구 구현
│   │   └── list-apps.ts            # list_apps 도구 구현
│   └── utils/
│       └── template.ts             # 템플릿 복사/변환 유틸리티
└── README.md

개발

# 개발 모드 (파일 변경 감지)
npm run dev

# 빌드
npm run build

# 빌드 후 직접 실행
npm start

관련 경로

  • 템플릿: /Users/seungmanchoi/works/react-native-fsd-template/

  • 앱 저장 위치: /Users/seungmanchoi/works/{slug}/

  • 공통 키 파일: /Users/seungmanchoi/works/common/

    • iOS API Key: AuthKey_6FD6879KFW.p8

    • Android 서비스 계정: works-488915-4f58ab8044c4.json

Available Tools

3 tools
list_appsA

Lists all Expo apps found in ~/works/ by scanning for app.json files with expo configuration. Shows app name, slug, bundle ID, version, and path for each app.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose real behavior: the scan is scoped to ~/works/ and keys off app.json files containing expo configuration, and it enumerates exactly what is returned. It does not cover edge cases such as a missing directory, empty results, or scan depth, keeping it short of a 5.

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?

Two tight sentences with the scope and mechanism front-loaded and the return fields following. No filler or redundant restatement of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param, read-only listing tool this is largely complete: it explains where it looks, how it finds apps, and what each result contains, which compensates for the absent output schema. Minor gaps remain around failure/empty-result behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The listed output fields are a useful addition even though they are not inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Lists), resource (Expo apps), the discovery mechanism (scanning ~/works/ for app.json with expo config), and the returned fields. This clearly distinguishes it from scaffold_app (creates) and setup_store_config (configures).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the discovery step before scaffolding or configuring an app, but the description never says when to call it or that it is the read-only precursor to the siblings. No exclusions or conditions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scaffold_appA

Scaffolds a new Expo + React Native app from the FSD template. Copies the template, updates app.json, package.json, eas.json, sets up i18n, and initializes a git repo.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesURL-safe slug for the app (e.g., "my-cool-app"). Used as the directory name under ~/works/ and in app.json slug. Must be lowercase letters, numbers, and hyphens only.
app_nameYesDisplay name of the app (e.g., "My Cool App"). Used in app.json as the expo name.
bundle_idNoBundle identifier for iOS/Android (e.g., "com.seungmanchoi.mycoolapp"). Defaults to com.seungmanchoi.{slug with hyphens removed}.
languagesNoSupported language codes for i18n (e.g., ["ko", "en", "ja"]). Defaults to ["ko", "en"]. Creates locale JSON files under src/shared/config/i18n/.
descriptionNoShort description of the app. Added to package.json.
theme_colorNoPrimary theme color hex code (e.g., "#6366f1"). Defaults to "#6366f1".

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It helpfully enumerates the side effects (copy template, modify config files, set up i18n, init git), which indicates a mutation that creates files and a git repo. However, it omits whether existing directories are overwritten, whether the operation is reversible, permission requirements, or what happens on partial failure.

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 efficient sentence that is front-loaded with the core action and follows with concrete effects. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter creation tool with no output schema and no annotations, the description is adequate but incomplete: it fails to cover error behavior, overwrite semantics, environment prerequisites, and success confirmation. The schema covers inputs well, but behavioral context around this mutation remains thin.

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?

Schema description coverage is 100%, so all six parameters are already well documented with examples and defaults. The description adds no parameter meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (scaffolds) and resource (Expo + React Native app from the FSD template), and lists concrete effects: copying the template, updating app.json/package.json/eas.json, setting up i18n, and initializing git. This clearly distinguishes it from siblings like list_apps (read-only inventory) and setup_store_config (configuration), which do not create apps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by defining what the tool does, but it offers no explicit when-to-use guidance, no prerequisites (e.g., Node/Expo CLI availability, working directory assumptions), and no mention of when not to use it versus alternatives. For a scaffolding mutation, this leaves the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

setup_store_configA

Configures App Store and Google Play submission settings for an existing Expo project. Sets up fastlane Appfile/Fastfile, updates eas.json submit section, and optionally configures AdMob.

ParametersJSON Schema
NameRequiredDescriptionDefault
platformsYesPlatforms to configure. Use ["ios", "android"] for both, or specify one.
admob_ios_idNoAdMob iOS app ID (e.g., "ca-app-pub-XXXXXXXX~XXXXXXXXXX"). If provided, configures react-native-google-mobile-ads plugin in app.json.
project_pathYesAbsolute path to the Expo project directory (e.g., /Users/seungmanchoi/works/my-app).
admob_android_idNoAdMob Android app ID (e.g., "ca-app-pub-XXXXXXXX~XXXXXXXXXX"). If provided, configures react-native-google-mobile-ads plugin in app.json.

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It does disclose the mutation targets (fastlane files, eas.json submit section, app.json for AdMob), which is meaningful. It does not state whether existing settings are overwritten, what credentials/auth are required, or whether changes are reversible.

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?

Two sentences, front-loaded with the core purpose and followed by the concrete side effects. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-file mutation tool with no annotations and no output schema, the description covers what gets written but omits prerequisites (account credentials, existing EAS project), overwrite semantics, and any indication of what is returned on success or failure. Adequate but with clear gaps.

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?

Schema description coverage is 100%, so the schema already documents all four parameters in detail. The description only adds that AdMob configuration is optional, which is already implied by the schema's conditional wording. Baseline 3 applies.

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 names a specific verb (configures) and resource (App Store and Google Play submission settings) and enumerates the concrete artifacts it produces (fastlane Appfile/Fastfile, eas.json submit section). This clearly separates it from siblings like scaffold_app, though it never explicitly names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"For an existing Expo project" implies a prerequisite (the project must already exist / be scaffolded), which is useful context. However, there is no explicit when-to-use vs when-not guidance and no mention of alternatives such as scaffold_app for new projects.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedlist_apps
    • First observedscaffold_app
    • First observedsetup_store_config
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: discovery, creation, and store configuration. No two tools overlap in action or resource, so an agent can easily select the right one.

Naming Consistency5/5

All tool names use consistent snake_case and follow a verb_noun pattern: list_apps, scaffold_app, setup_store_config. The convention is predictable throughout.

Tool Count5/5

Three tools are appropriately scoped for a specialized Expo app scaffold server. Each tool covers a distinct phase of the workflow without unnecessary bloat.

Completeness4/5

The surface covers discovery, creation, and store configuration, which are the core workflows. Minor gaps exist around updating or removing existing apps, but these are not central to the stated scaffold purpose.

Resources

Related MCP Connectors

Related MCP Servers

  • Expo MCP Server

    CaullenOmdahl
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables programmatic interaction with Expo/React Native projects and EAS (Expo Application Services) for managing builds, publishing OTA updates, submitting apps to stores, and accessing comprehensive documentation.
    5
    MIT

  • Expo MCP Server

    DaveDev42
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables automated testing and development of Expo/React Native apps through session-based Expo dev server management and Maestro UI automation tools for tapping, text input, screenshots, and flow execution.
    126,438 npm
    5
    MIT

  • Expo MCP Server

    tomoyasu-sasaki
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    A Model Context Protocol server designed to streamline Expo and React Native development for AI assistants like Cursor and Claude. It provides a comprehensive suite of tools for project initialization, EAS builds, OTA updates, and development server management.
    1
    -