Which integrations are available for this server?

Scans iOS/macOS code for Apple App Store policy compliance, detecting required reason API declarations, privacy manifest issues, and rejection codes. Integrates with GitHub via SARIF upload to render inline PR annotations for policy violations detected during CI scans. Scans Android code for Google Play policy compliance, covering restricted permissions, data safety categories, and foreground service requirements.

How do I use store-preflight-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@store-preflight-mcp Scan my project for app store rejection risks." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

store-preflight-mcp

by asif786ka

Overview Schema Source Related Servers Discussions Admin

Python

Local

store-preflight-mcp

PyPI Python License: MIT Tests

Your agent just wrote code that will get your app rejected. It has no idea.

An MCP server that maps API usage → required declaration → dated policy, so a coding agent finds out at write time instead of from an App Store Connect email three days after the PR merged.

$ store-preflight scan . --date 2026-07-15

🛑 UserDefaults requires a declared reason in PrivacyInfo.xcprivacy
    ITMS-91053
    No PrivacyInfo.xcprivacy exists anywhere in this project. Code touches
    UserDefaults APIs, so App Store Connect will refuse the upload.
      → ios/RejectedApp/AnalyticsModule.swift:7  private let defaults = UserDefaults.standard
    fix: PrivacyInfo.xcprivacy → NSPrivacyAccessedAPICategoryUserDefaults

✗ failing: 7 finding(s) at or above blocker

That's the whole product. An agent adds an analytics module, touches UserDefaults, and nothing in the world tells it that Apple has required a CA92.1 entry in a file it has never heard of since 1 May 2024. The binary is rejected days later, by which point nobody remembers which PR did it.

Doc MCPs describe APIs. None of them map an API to the declaration it obliges, or to the date that obligation acquired teeth.

Why dates are the whole design

This is the sibling of mobile-docs-mcp, and it reuses its core insight. There, a symbol isn't "real" — it's real within a version range (since / deprecated / removed). Here, a rule isn't "true" — it's true within a date window:

PolicyWindow(
    announced     = "2023-06-05",   # WWDC23
    warning_from  = "2024-03-13",   # email only, upload still succeeds
    enforced_from = "2024-05-01",   # hard block
)

PolicyWindow.status_on(date) is the direct analogue of VersionRange.status_at(version). Same model, different axis — because store policy ships on deadlines, not releases.

This isn't decoration. It's what makes the tool usable:

Severity follows the calendar. A blocker that doesn't bite until October is reported as a warning in July, automatically. Nobody hand-edits severities as deadlines pass.
You can scan the future. --date 2026-10-28 tells you what breaks when a deadline lands, before it lands.
The tests don't rot. Every assertion is pinned to a fixed date, so the suite doesn't silently change verdict when a deadline passes.

The same unchanged repo, scanned on two dates:

$ store-preflight scan . --date 2026-07-15
ℹ️  Geofencing is no longer an approved use case for a location foreground service
⚠️  READ_CONTACTS requires a declaration for apps targeting Android 17+

$ store-preflight scan . --date 2026-10-28
⚠️  Geofencing is no longer an approved use case for a location foreground service
🛑 READ_CONTACTS requires a declaration for apps targeting Android 17+

Not one byte of that repo changed. That failure mode is invisible to every other tool in the toolchain — a linter diffs your code, and your code is fine.

(Why does READ_CONTACTS escalate to a blocker while geofencing stops at a warning? Because the permission string is either in your manifest or it isn't, whereas whether geofencing is what justifies your location FGS depends on a form you filed in Play Console, which isn't in the repo. See On being trustworthy.)

Related MCP server: @squirex.dev/mcp-server

Install

uvx store-preflight-mcp          # MCP server (stdio)
pipx install store-preflight-mcp # CLI too

Claude Code / any MCP client:

{
  "mcpServers": {
    "store-preflight": {
      "command": "uvx",
      "args": ["store-preflight-mcp"]
    }
  }
}

Zero non-mcp runtime dependencies. No crawl, no API key, no network. The ruleset ships as Python and the whole scan is local.

Tools

Tool	Use
`preflight_scan`	Scan a repo. What will be rejected, where, and why.
`check_api_declaration`	Before writing: "I'm about to use `UserDefaults` — what must I declare?"
`get_required_declaration`	The exact key + reason code + paste-ready snippet.
`explain_rejection`	Paste `ITMS-91053` from the email → a concrete fix.
`list_policy_deadlines`	The dated calendar. What's enforced, what lands next.

check_api_declaration is the one that changes agent behaviour — it's cheap enough to call before writing the code, which is the only time the answer is free.

> check_api_declaration("UserDefaults", store="apple")

🛑 BLOCKER · status enforced — enforced since 2024-05-01 (806 days ago)

You must declare: NSPrivacyAccessedAPICategoryUserDefaults in PrivacyInfo.xcprivacy

Valid values:
  · CA92.1 — Read/write info accessible only to the app itself...
  · 1C8F.1 — ...only to apps, extensions and App Clips in the same App Group...
  · C56D.1 — Third-party SDK only: wrapper function around UserDefaults...
  · AC6B.1 — Read com.apple.configuration.managed (MDM managed app config)...

CI

- run: pipx install store-preflight-mcp
- run: store-preflight scan . --format sarif -o preflight.sarif
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: preflight.sarif }

SARIF means findings render as inline PR annotations, on the line that caused them. --fail-on blocker (the default) exits non-zero, so a rejection becomes a red check instead of an email.

Coverage

App Store

All 5 required-reason API categories, all 17 reason codes, each with Apple's verbatim meaning — UserDefaults, FileTimestamp, SystemBootTime, DiskSpace, ActiveKeyboards
17 Info.plist purpose strings, incl. the iOS 17 calendar split (NSCalendarsFullAccessUsageDescription) most projects still miss
Privacy manifest validity: ITMS-91054 / 91055 / 91056
All 86 privacy-impacting SDKs + npm/pub → framework aliasing
NSPrivacyTracking without NSPrivacyTrackingDomains
The Xcode 26 / iOS 26 SDK upload gate (since 2026-04-28)
All 6 ITMS rejection codes decoded

Google Play

Restricted permissions: QUERY_ALL_PACKAGES, MANAGE_EXTERNAL_STORAGE, SMS/Call Log, ACCESS_BACKGROUND_LOCATION, REQUEST_INSTALL_PACKAGES, USE_EXACT_ALARM, USE_FULL_SCREEN_INTENT, accessibility, photo/video
14 data safety categories with their data types
All 14 foreground service types (including mediaProcessing, which most lists miss), each with its required permission and runtime prerequisite
Advertising ID, including the auto-merged-from-play-services-ads trap
New for 2026: the Contacts policy (2026-10-28) and the geofencing withdrawal (2026-08-26)

Languages: Swift, Objective-C, Kotlin, Java, JS/TS, Dart — plus Info.plist, PrivacyInfo.xcprivacy, AndroidManifest.xml, package.json, pubspec.yaml, Podfile. React Native, Flutter and native all work; no build required.

On being trustworthy

A preflight tool that cries wolf gets --ignored within a week, and then it may as well not exist. Three deliberate concessions:

Findings carry their own epistemics. Apple's required-reason rules are mechanically checkable: the symbol is in your binary or it isn't. Play's data safety form is not — it keys on transmission off-device, not on holding a permission. Google says plainly that on-device processing needs no disclosure. So READ_CONTACTS does not imply a Contacts disclosure, and every such mapping is marked heuristic: it raises a question, and a heuristic finding can never fail your build (enforced by a test).

The target API level is not hardcoded. When this ruleset was built (2026-07-15), Google's own timeline page was internally inconsistent — metadata dated May 2026, content still describing the August 2025 / API 35 deadline — and no API 36 announcement existed on any Google property, despite third-party blogs confidently asserting one. So the rule is encoded ("within one year of the latest major Android release") along with last_verified and a needs-live-check flag. A tool that states a fake deadline confidently is worse than one that says "verify this".

The SDK check is a prompt, not a verdict. Apple's requirement attaches when an app is new or an update adds a listed SDK — not to every app that contains Firebase. And "any SDKs that repackage those on the list" are included, so exact matching under-detects. Both facts make a confident verdict impossible, so it ships as a warning that says why.

What we do not concede: comments and string literals are stripped before symbol matching (with line numbers preserved), node_modules/Pods are never walked, and tools:node="remove" is honoured — so the correct way to drop the auto-merged AD_ID permission isn't reported as the violation.

Verify it

python smoke_test.py

70 assertions, no network. Four fixture repos: one that gets rejected, the same app fixed, a manifest that is wrong on its own terms, and one whose code never changes while the policy date moves under it. The suite also pins the facts that are easy to get wrong:

✓ exactly 5 required-reason categories
✓ exactly 17 reason codes
✓ 86 SDKs on the commonly-used list
✓ getattrlist maps to BOTH FileTimestamp and DiskSpace (not 1:1)
✓ ITMS-91054 title is 'Invalid API category declaration'
✓ 14 foreground service types incl. mediaProcessing
✓ target SDK is a rule, not a hardcoded literal
✓ no heuristic finding is ever a blocker

Those aren't padding — each one is a mistake that was actually made and caught during the build. getattrlist really does oblige two separate declarations. The SDK list really is 86, not 87, because Apple publishes "BoringSSL / openssl_grpc" as one entry.

See RULES.md for provenance — every rule's source, and the 18 traps that make this domain hostile to naive implementations (Apple's docs are JS-rendered shells; there's a JSON feed that isn't).

Licence

MIT

Available Tools

5 tools

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 UserDefaults, android.permission.READ_SMS, or a new SDK, and you will not find out from a rejection email days later.

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).

ParametersJSON Schema

Name	Required	Description	Default
`api`	Yes
`store`	No
`scan_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It implies a read-only check but does not explicitly state safety, rate limits, or prerequisites beyond what is implied by 'check'. Examples of parameters are given but behavioral traits are minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with a clear header, explanatory paragraph, and Args section. Slightly verbose but front-loads purpose and provides necessary context without being overly long.

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?

Given presence of an output schema (not shown), description does not need to explain return values. It covers when to use, what inputs to provide, and gives a real-world use case. Missing info about output format is acceptable due to output schema.

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?

Schema coverage is 0%, but description adds significant meaning: examples for api, options for store, and ISO date format for scan_date. This compensates well for the bare schema.

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?

Description clearly states the tool checks what an API, permission, or SDK obliges you to declare before writing code. Provides specific examples and distinguishes from sibling preflight_scan, making purpose unmistakable.

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

Usage Guidelines4/5

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

Explicit guidance to use before adding new APIs/permissions/SDKs to avoid rejection. Mentions it is the 'pre-write counterpart to preflight_scan', though could more thoroughly contrast with all siblings like explain_rejection.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/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 burden. It indicates the tool is a lookup/decoding operation (no destructive effects), but does not explicitly confirm read-only behavior, auth requirements, or any rate limits. The description is adequate but could be more explicit.

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 concise (two sentences plus an Args block), front-loads the key purpose, and has no unnecessary words. Every sentence serves a purpose.

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?

Given the tool's simplicity (one required parameter, output schema exists), the description is adequately complete. It explains what the tool does, what input to provide, and how to use it. The output schema presumably documents the return value, so no further detail is needed.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning beyond the schema by explaining that the parameter can be a specific code (e.g., 'ITMS-91053') or the full email text, clarifying the acceptable input format.

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 clearly states the tool's purpose: 'Decode an App Store rejection code (ITMS-91053 etc) into a concrete fix.' It provides a specific verb ('Decode') and resource ('App Store rejection code'), and distinguishes from sibling tools (which focus on API declarations, policies, scans) by context.

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

Usage Guidelines4/5

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

The description gives explicit usage guidance: 'Paste the code from the App Store Connect email.' It also explains the input format ('code: e.g. "ITMS-91053", or the full email text'). While it doesn't explicitly state when not to use it, the sibling tools are clearly different, making the use case obvious.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`rule_id`	Yes
`reason_code`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/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 full burden. It implies a read-only operation by stating 'Get', but does not explicitly disclose side effects, permissions, or limitations. Adequate but not thorough.

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 concise, with a single sentence for purpose followed by two bullet-like parameter explanations. No redundant information.

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

Completeness5/5

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

Given the tool's low complexity (2 parameters with examples) and the existence of an output schema, the description sufficiently covers inputs. The return type is hinted by 'exact declaration and paste-ready snippet', and the output schema handles details.

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

Parameters5/5

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

Schema description coverage is 0%, but the description provides clear examples and default behavior for both parameters (e.g., 'apple.rr.user_defaults' for rule_id, 'CA92.1' for reason_code), adding significant meaning beyond the raw schema.

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 clearly states it retrieves 'the exact declaration and a paste-ready snippet for a rule,' which is a specific verb and resource. This distinguishes it from sibling tools like check_api_declaration or preflight_scan.

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

Usage Guidelines4/5

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

The description advises that rule_id comes from preflight_scan output, implying usage after that step. It also explains reason_code tailoring, giving context for use, but does not explicitly compare with alternatives or state when not to use.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`store`	No
`scan_date`	No
`upcoming_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It states the tool 'shows' data, implying read-only, but does not disclose other behavioral traits like auth needs, rate limits, or side effects. The lack of behavioral depth limits transparency.

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?

Description is concise, front-loaded with the tool's purpose, and each sentence adds value. The rationale about deadlines vs. releases is included efficiently, and parameter descriptions are compact.

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?

Given the tool's simplicity (3 parameters, no required, output schema exists), the description covers usage context and parameter semantics adequately. It lacks return value explanation but the output schema handles that. Minor gaps exist (e.g., no pagination info) but overall complete for a list tool.

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?

Schema coverage is 0% but description provides clear semantics for all three parameters: store ('apple'/'play'/'') , scan_date (ISO date), upcoming_only (boolean). This adds significant meaning beyond the schema's type/default information, helping agents understand valid 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?

Description clearly states the tool shows a dated policy calendar, with context about how store policies are schedule-based rather than release-based. This differentiates from sibling tools like check_api_declaration or explain_rejection, which serve different purposes.

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?

Description implies usage for checking policy requirements relative to dates, but does not explicitly state when to use this tool over alternatives or provide exclusions. The context about deadlines vs. releases gives implicit guidance but lacks direct when/when-not instructions.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`store`	No
`severity`	No
`scan_date`	No
`include_snippets`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 full burden. It discloses that it reads specific files, compares code against declarations, and notes that scan_date affects verdicts. It doesn't mention performance or side effects, but transparency is good overall for a scan tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise with a brief intro and structured Args section. It could be slightly more terse, but all sentences add value. The structure is clear and front-loaded with purpose.

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?

Given 5 parameters, no annotations, and presence of output schema, the description covers the main behaviors and parameters. It does not explain return values (but output schema exists), and lacks details on output format. Still, it is sufficiently complete for a scanning tool.

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

Parameters5/5

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

Schema coverage is 0%, so the description compensates fully. Each parameter is explained with additional context: e.g., 'scan_date' can be a future date to preview deadlines, 'store' is 'apple'/'play'/'', 'severity' as min level. This adds significant meaning beyond the schema titles.

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 clearly states the tool scans a mobile app repo for rejections before submission, specifying files read (Info.plist, etc.) and what it reports. It distinctively covers comprehensive scanning, differentiating from siblings like 'check_api_declaration' or 'explain_rejection'.

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 use before submission but provides no explicit when-to-use, when-not-to-use, or comparison with siblings. Usage context is implied through 'before submission' but lacks explicit guidance on alternatives.

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.

5 tool updatesv0.1.1Jul 15, 2026
- First observedcheck_api_declaration
- First observedexplain_rejection
- First observedget_required_declaration
- First observedlist_policy_deadlines
- First observedpreflight_scan

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.1/5.0

Scored 2026-07-15 15:30 across 5 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

registry A
com.policylayer
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Security Developer Tools
521
Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
Compuute MCP Security Scanner A
io.github.Compuute
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Security Code Analysis Version Control
12

Related MCP Servers

Code-Oracle
Code Analysis Security Developer Tools
Sri-Lohith-Mulugu
F
license
Not graded
quality
D
maintenance
MCP server for automated architectural mapping, security vulnerability detection, ML asset tracking, and code metrics in local repositories.
Updated 5 months ago (2026-04-21 10:35 UTC)
-
@squirex.dev/mcp-serverofficial
Security Code Analysis Testing & QA Tools
SquireX-dev
A
license
A
quality
D
maintenance
MCP server that scans Salesforce Agentforce metadata for security vulnerabilities using 61+ SAST rules, integrating into AI coding workflows to guard against OWASP LLM top 10 risks.
Updated 5 months ago (2026-04-20 23:42 UTC)
16
5 npm
Cryptographic Autonomy 1.0 (Combined Work Exception)
safe-code-mcp
Code Analysis Security File Systems
marcojourney
F
license
Not graded
quality
D
maintenance
A local MCP server that provides controlled repository access with policy-based file filtering, secret redaction, and audit logging for AI coding agents.
Updated 3 months ago (2026-06-18 09:02 UTC)
-
Security Scan MCP Server
Code Analysis Security
chrischabot
A
license
Not graded
quality
D
maintenance
An MCP server that provides CVE-driven security prompts for code review, enabling coding agents to get actionable security checks based on real vulnerabilities.
Updated 8 months ago (2026-01-08 21:33 UTC)
MIT

store-preflight-mcp

Why dates are the whole design

Install

Tools

CI

Coverage

On being trustworthy

Verify it

Licence

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@squirex.dev/mcp-serverofficial