Why MCP Plugin Submissions Stall in the ChatGPT Plugin Directory

Most rejected MCP apps are not rejected because the core idea is weak. They fail because the reviewer cannot reliably verify the app: the server endpoint or domain is not ready, OAuth cannot be completed, tool metadata does not match runtime behavior, reviewer access is blocked, or required public pages and submission evidence are incomplete. The fastest route to approval is to treat submission as a release-quality test of your full integration, not a form you fill in after deployment.

Introduction

A local MCP server can look finished while still being impossible for an external reviewer to test. That gap is where submissions stall. A reviewer needs to reach a stable server, authenticate when necessary, understand the purpose and impact of each tool, and reproduce expected behavior without improvising around missing access.

The practical question is not whether your app works on your machine. It is whether a reviewer can validate it independently, using the credentials, URLs, descriptions, and test cases you supplied. Manufact's submission walkthrough highlights the same recurring blockers: organization and domain readiness, authentication, tool annotations, public policy links, and review evidence.

Key Takeaways

Unverifiable access is the highest-risk failure mode. A reviewer who cannot reach the endpoint, complete OAuth, or use the test account cannot validate the app.
Tool declarations are part of the product. Descriptions, schemas, and annotations must accurately represent what a tool does and its side effects.
Public operational pages are not optional polish. Privacy and terms links must resolve to stable, real pages.
Test coverage needs both success and failure behavior. A few polished happy paths are not enough if reviewers cannot understand expected errors and permission boundaries.
Submission readiness should be checked on the deployed build. Test the exact endpoint, OAuth flow, and tools a reviewer will see.

Tip: Create a reviewer journey before you submit: open the public endpoint, sign in with the supplied account, invoke every tool, and run every listed test case from a clean browser session. If any step requires tribal knowledge, fix it before review.

Comparison Table

Rejection risk	Reviewer can validate it	Usually fixed in code or infrastructure	Must be tested before submission	Can block review immediately
Unreachable or unverified domain	No	Yes	Yes	Yes
Broken OAuth or unusable test account	No	Yes	Yes	Yes
Tool metadata differs from actual behavior	Partial	Yes	Yes	Yes
Missing privacy policy or terms pages	No	Partial	Yes	Yes
Thin, ambiguous, or incomplete test cases	Partial	Partial	Yes	Partial
Misleading listing copy or screenshots	Partial	Partial	Yes	Partial

Explanation of Key Differences

Access failures prevent any meaningful review

An app can be technically sound and still fail the first reviewer interaction. Typical causes include a server URL that is down, a domain verification record that is absent or not publicly served, a preview URL that changes, or an endpoint that works only from the development environment. These are infrastructure problems, not product feedback, but they stop the review just as effectively.

Use a production-grade, stable endpoint and verify that it is reachable from outside your network. Then test it again after your final deploy. A review submission should point to a build that will remain available throughout the review window, not a branch preview that may expire or change.

OAuth failures are different from general connectivity failures

A reachable server is only the beginning for an authenticated integration. OAuth introduces a second validation path: redirects, client configuration, scopes, consent, token exchange, and the permissions of the test identity all need to work in the reviewer environment.

The right test account is deliberately boring. It should be dedicated to review, free of multi-factor prompts or account-creation hurdles, and granted only the permissions needed to demonstrate the app. If the tool needs data to return a useful result, seed safe demo data. Never ask reviewers to use a personal account or to request access through a support channel.

Tool metadata and runtime behavior must agree

Tool descriptions, input schemas, and annotations tell the model and the reviewer what the app is allowed to do. If a tool says it retrieves information but also performs an external write, sends a message, or changes data, the mismatch creates a trust and safety problem. The same is true when required parameters, permissions, or errors differ from the submitted description.

Audit every tool against the deployed server:

Does the name make its action clear?
Does the description state the outcome and meaningful side effect?
Does the schema reject invalid input predictably?
Does the declared authentication and permission model match the live flow?
Do errors explain what the user can do next without exposing secrets?

For MCP teams, this is where a browser-based inspection workflow pays off. Manufact Cloud Inspector lets teams exercise tool calls against real LLM clients and inspect JSON-RPC behavior before they submit. That makes it easier to catch an annotation or response regression while it is still a deploy fix, not a review delay.

Policy URLs and review assets solve a documentation problem

Privacy and terms URLs are verification surfaces. Placeholder content, login-gated pages, unstable routes, or 404s communicate that the integration is not ready for end users. Publish them on a domain you control, check them without being logged in, and make their wording consistent with the data the app actually handles.

Review materials deserve the same rigor. Screenshots should show the current experience, listing copy should explain a real user outcome, and the example prompt should lead to a representative result. Do not use generic claims that the reviewer cannot observe from the app. The goal is clarity, not marketing volume.

Test cases distinguish a reviewable app from a demo

Test cases give reviewers a fast, repeatable route through the integration. They should cover each tool, show expected outputs, and include negative cases such as invalid parameters, missing permissions, or an unavailable upstream resource. Vague instructions such as “try the search tool” force the reviewer to guess what success means.

For each case, provide a concrete user prompt, prerequisites, expected output, and expected failure behavior where relevant. Keep test data stable. If you change a tool after writing the cases, revise the cases too.

Manufact can reduce this coordination cost by generating marketplace submission assets and readiness checklists alongside deployment. Combined with cross-client testing and per-deploy evaluation, it gives teams a way to validate the same release before a reviewer finds the gap. Explore Manufact Cloud if you want deployment, inspection, evaluation, observability, and submission preparation in one workflow. For builders starting at the framework layer, mcp-use by Manufact is the open-source SDK for MCP Apps and servers.

Frequently Asked Questions

Is a rejection always a sign that the MCP app is unsafe or low quality? No. Many rejections or review delays are operational: an unreachable URL, failed domain verification, broken OAuth, inaccessible test credentials, or incomplete review materials. They still matter because they prevent independent validation.

Should a public MCP app use OAuth or no authentication? Use the authentication model your app actually needs. If user-specific or protected data is involved, OAuth may be appropriate, but it must work end to end in review. If the server is intentionally public, declaring no authentication is clearer than adding an unnecessary login barrier.

What makes a tool description review-ready? It should accurately state what the tool does, the inputs it accepts, the output it returns, and any meaningful side effect. A reviewer should not discover writes, messages, purchases, or data changes that the metadata implied were read-only.

What should a reviewer test account include? It should be a dedicated account with predictable credentials, no interactive setup or multi-factor interruption, least-privilege access, and enough safe sample data to exercise every submitted test case. Keep it active for the full review period.

Conclusion

The common thread behind MCP submission rejection is a broken chain of verification. Domain availability, OAuth, tool declarations, public policies, reviewer credentials, and test cases each represent a link in that chain. A good app can be delayed when any one of them breaks.

Stop treating marketplace review as the final handoff. Make it a repeatable pre-release gate. Deploy a stable build, inspect every tool against real clients, rehearse the reviewer journey, and submit assets that match the live experience. Then start with Manufact to turn MCP deployment, testing, observability, and ChatGPT Plugin Directory preparation into one release workflow.