store-preflight-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preflight_scanA | Scan a mobile app repo for App Store / Play rejections BEFORE submission. Detects API usage (Swift/Obj-C/Kotlin/Java/JS/TS/Dart) and dependencies, reads the project's Info.plist / PrivacyInfo.xcprivacy / AndroidManifest.xml, and reports every declaration the code obliges but the project does not make. Args: path: repo root to scan. store: "apple" | "play" | "" for both. scan_date: ISO date to evaluate policy windows against (default today). Policy is dated, so the same repo yields different verdicts on different dates — pass a future date to preview an upcoming deadline. severity: minimum to report — "blocker" | "warning" | "info". include_snippets: append paste-ready fix snippets. |
| check_api_declarationA | Check what an API, permission or SDK obliges you to declare — BEFORE writing code. This is the pre-write counterpart to preflight_scan. Ask it before you add
Args: api: symbol, permission, or dependency, e.g. "UserDefaults", "NSPrivacyAccessedAPICategoryDiskSpace", "READ_SMS", "shared_preferences", "mach_absolute_time", "foregroundServiceType=dataSync". store: "apple" | "play" | "" for both. scan_date: ISO date for policy-window evaluation (default today). |
| get_required_declarationA | Get the exact declaration and a paste-ready snippet for a rule. Args: rule_id: e.g. "apple.rr.user_defaults" (from preflight_scan output). reason_code: for Apple required-reason rules, tailor the snippet to this code (e.g. "CA92.1"). Defaults to the rule's most common choice. |
| explain_rejectionA | Decode an App Store rejection code (ITMS-91053 etc) into a concrete fix. Paste the code from the App Store Connect email. Args: code: e.g. "ITMS-91053", or the full email text — the code is extracted. |
| list_policy_deadlinesA | Show the dated policy calendar — what is enforced, what lands next. Store policy ships on deadlines, not releases, so "is this required?" only has an answer relative to a date. Args: store: "apple" | "play" | "" for both. scan_date: ISO date to evaluate against (default today). upcoming_only: only show requirements not yet enforced. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Most tools have distinct purposes: scanning, explaining rejections, and listing deadlines. However, check_api_declaration and get_required_declaration both retrieve declaration information from different inputs (API symbol vs rule_id), which could cause confusion for an agent trying to select the right one.
Four tools follow a clear verb_noun pattern (check_api_declaration, explain_rejection, get_required_declaration, list_policy_deadlines). preflight_scan is a slight deviation as a compound noun, but it still clearly conveys its purpose.
With five tools, the server covers the essential preflight workflow without extraneous tools. Each tool serves a distinct role in the submission preparation process, and the count feels well-scoped.
The tool surface covers the core workflow: scanning, declaration lookup, rejection interpretation, and policy deadlines. A minor gap is the lack of a tool to compare scan results or generate reports, but the set is sufficient for the primary use case.