Last week we released Beacon, a tool that audits your MCP app before you submit it to the ChatGPT store and Claude Connectors directory. It checks protocol compliance, tool quality, widget rendering, security, edge-case input handling, and more. If your app passes Beacon, it's technically solid. But technically solid and approved by the various directories are not the same thing, and the gap between the two is where many submissions get stuck.

Over the course of dozens of submissions, we’ve compiled a list of the reasons that OpenAI uses when they send an app back. And guess what? A significant portion of them have nothing to do with the app itself. They're about the submission: the credentials you provided, the test cases you wrote, the screenshots you uploaded, and the privacy policy you linked to... 

Some rejections are easy to understand (wrong category, description that doesn't match the app, missing support contact…). We won’t spend time on those. This article explores some of the less obvious reasons why apps get rejected, and what you can do to avoid it!

1. Connectivity issues

The most common blocker, the one that stops everything else from being evaluated, is a failure to connect. The reviewer tries to reach your MCP App using the URL and credentials you provided in the submission form, and can't. This might be a typo in the URL, credentials that work in your environment but weren't set up for external access, or an app that was working at submission time and went down before the reviewer got to it.

The fix sounds obvious, but it catches more submissions than you'd expect: test your MCP URL and credentials from a clean environment, not from a machine that's already authenticated or whitelisted, immediately before you submit.

If your app requires authentication, make sure the demo account you provide doesn't require MFA, one-time codes, or any extra setup steps, as reviewers won't be able to complete those.

2. Test cases

This is the one that comes up most often across our submissions. OpenAI requires you to submit test cases as part of the review process: specific prompts & expected outputs/user flow. Reviewers will run these verbatim to verify your app does what it claims. If these prompts fail, produce unexpected results, or don't actually trigger the app's core functionality, the submission comes back. Most importantly, these tests needs to pass on desktop, Android, and iOS.

First, make sure your test cases are not too vague (this is a reason for rejection that we have seen a few times). The form asks for user prompts and descriptions of what the app is expected to do after the prompt. "Find me a hotel in Paris for next weekend" + “A widget of hotel displays; clicking on a hotel opens a detail card in fullscreen” is a good test case. Reviewers run exactly what you give them. If the prompt is underspecified, the result is unpredictable and the submission fails.

Second, make sure your tool descriptions are detailed enough that the model fully understands how to use them. If your test cases pass locally but fail in review, the issue can be in the tool description rather than the tool itself.

3. Naming

This one catches developers off guard because it has nothing to do with how the app works. Two distinct naming issues come up in reviews: a name that's too generic (think "Chess Game" or "Travel Search"), and a name that incorporates a trademarked term or appears to impersonate an existing brand. Both are judged by the reviewer, which means the bar isn't always predictable, but if your app name could plausibly be confused with another product or company, reconsider before you submit rather than after.

In addition to your app name, make sure the name you enter as the developer must match your verified individual or business name exactly. Even a minor mismatch is grounds for rejection.

4. Visual materials

Several common rejections come entirely from how the submission form is filled out.

Screenshots. OpenAI provides a Figma template that defines exactly how screenshots should be laid out and what they should show. Submissions using screenshots taken outside this template, or showing the wrong UI states (for instance, your screenshot shouldn’t include the ChatGPT interface), get rejected on this basis alone.

Demo video. The video you submit needs to show the app working on desktop, iOS, and Android. Even if it shows the entire feature set, a video that only covers one platform will get flagged. Reviewers specifically check that the mobile experience is demonstrated, so if your widget behaves differently on a smaller screen, that needs to be visible in the video.

5. Legal & advertising

Privacy policy issues show up in two forms. The first is a policy that's missing, incomplete, or buries disclosures in language that isn't clear. The second, subtler version: your app returns user-related data in tool responses that isn't explicitly covered in the policy. Reviewers can be fairly defensive and might flag fields that “seem” to be user related but not listed in your policy. Make sure to review the outputs of your tool and avoid ambiguous fields. Reviewers check what your tools actually return, not just what the policy claims.

A related issue that comes up less often but is worth knowing about: apps that include what reviewers interpret as advertising. This can be triggered by unnecessary brand mentions, promotional language inside the widget UI, or links that read as sponsored placements.

6. Tool hints

Every tool has three annotations: readOnlyHint (does it change anything?), destructiveHint (could it permanently modify or delete data?), and openWorldHint (does it call external services?). All three must be explicitly set to true or false on every tool, and they need to accurately reflect actual behavior, otherwise reviewers flag it. Beacon validates that annotations are present, but accurately describing what a tool does is a judgment call that requires a human.

7. URL safety

If your app fetches data from domains not explicitly listed in your CSP, the submission will fail. Audit every URL your widget fetches from before submitting and configure your content security policies as needed. 

8. UI quality

While many UI issues can prevent an app from being approved, one less obvious rejection comes down to dark mode. ChatGPT supports both light and dark themes, and reviewers test in both. An app that looks fine in light mode but has poor contrast, invisible text or broken layouts  in dark mode will fail on UI/UX quality grounds even if every functional check passes. Test your widget in both modes before submitting.

What this means in practice

Most of these rejections are fixable quickly. The problem is that you only find out about them after a full review cycle, which can take days or weeks. That's the real cost: not the fix itself, but the lag between submitting, waiting, and discovering something you could have caught before you hit send.

Beacon handles the technical layer. The submission layer is on you (well at least for now, but more on that later ;) ), but now you know what to look for. Run Beacon before you submit, then use this list for everything else!