There is no single “MCP store” review process: OpenAI’s directory, Microsoft’s MCP certification, Autodesk’s marketplace, and Anthropic’s directory each set different requirements. Start with the destination’s current rules; the checks below are a cross-platform triage guide, not a substitute for that platform’s checklist. If a rejection gives little detail, use the same checks to turn it into a reproducible issue before resubmitting.
First, identify which review you are preparing for
These destinations differ in eligibility, endpoint requirements, package materials, and review evidence. Microsoft describes its certification workflow as a preview, so its process may change. Check the live requirements for your target immediately before submitting.
As an Amazon Associate I earn from qualifying purchases.
| Destination | What to verify | Important distinction |
|---|---|---|
| OpenAI directory | Verified publisher identity, a public production endpoint, submission materials, tool scan and domain verification, plus usable review credentials when authentication is required. | An approved plugin still must be published from the portal before it appears in the directory; enhanced distribution is selective. OpenAI review requirements and submission guidance. |
| Microsoft MCP certification | Publisher eligibility, endpoint ownership or control, Partner Center submission, package validation, authentication readiness, and functional and safety evaluation. | This is a certification workflow, not simply a directory form. Microsoft’s guidance labels it preview. Microsoft certification guidance. |
| Autodesk marketplace | A complete tool manifest and publisher security declaration, including applicable tools, resources, prompts, APIs, providers, and external endpoints. | Focus on accurate disclosures, HTTPS, and access to only the data needed for the service. Autodesk publisher guidance. |
| Anthropic directory | Review the current directory policy, including its requirements for safety, security, compatibility, and documentation of operation, purpose, and troubleshooting. | The available policy excerpt identifies these review areas, but does not establish granular current requirements. Verify the live policy before relying on specifics. Anthropic directory policy. |
Check publisher eligibility and endpoint access
Verify the publisher identity
Use the intended individual or business identity and complete the target platform’s verification steps. OpenAI states: “Publishing under an unverified individual or business name will result in rejection.” For Microsoft certification, the publisher must be verified and enrolled in the Microsoft 365 and Copilot program. If you do not own or control the service endpoint, Microsoft’s guidance calls for partnering with its owner or completing the necessary verification.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Prove the production endpoint is reviewable
For an OpenAI remote MCP submission, use a publicly accessible production server on a production domain, not a local or test endpoint. Check the exact submitted URL from outside your company network. If you use a template URL, make sure the concrete review endpoint works and matches the submitted pattern. Microsoft also treats endpoint ownership and authentication readiness as prerequisites; follow its supported authentication and test-configuration guidance.
#1 Best Overall
Exercise the reviewer’s authentication path
If OpenAI reviewers need to sign in, test the exact credentials and flow you provide. Its guidance calls for a fully featured demo account with sample data; an extra account-creation step or an inaccessible two-factor authentication step can block review. For other destinations, confirm that the reviewer can complete the documented authentication setup with the supplied materials.
Validate the package and listing before submission
Check every field against the target’s current limits
For OpenAI remote MCP submissions, the current submission-error guidance sets a maximum of 4,000 characters for the long description and 30 characters each for the display name and short description. Those are OpenAI-specific limits, not general MCP directory rules. OpenAI also requires HTTPS policy and support URLs for remote MCP submissions. Confirm names, descriptions, categories, URLs, developer identity, and supported text against the live form rather than reusing limits from another store. OpenAI submission-error guidance.
Rank #2
Gather the required reviewer materials
- OpenAI remote MCP: provide a demo-recording URL, exactly five positive and three negative test cases, release notes, and the required listing URLs, including policy and support pages.
- Microsoft certification: prepare the package files and metadata its current guidance requests, including a manifest, tool file,
intro.md, and authentication configuration. Also check icons, public documentation, support, privacy and terms information, and publisher metadata. Evaluation evidence can help validate behavior when available. - Autodesk marketplace: complete the tool manifest and publisher security declaration. Include all applicable tools, resources, prompts, external endpoints, Autodesk APIs, and AI providers.
These lists are platform-specific: a complete package for one destination does not establish that another will accept the same files or evidence.
Make declarations match what the server actually does
Audit tool names, descriptions, and annotations
For OpenAI remote MCP tools, set accurate readOnlyHint, openWorldHint, and destructiveHint values and provide a justification for each. Use names and plain-language descriptions that describe the real action; avoid promotional labels or opaque internal jargon. Explain requested permissions and keep them limited to what the plugin needs. OpenAI also requires a successful, current tool scan and completion of the domain-verification challenge. OpenAI submission-error guidance and OpenAI review guidelines.
Reconcile manifests, endpoints, and deployed behavior
For Autodesk, compare the manifest and security declaration with the deployed server: missing tools, undeclared endpoints, or differences between declared and actual behavior can create review issues. Declare external domains and connections, use HTTPS, and request only the data needed for functionality. If an OpenAI UI embeds third-party domains, document why each domain is needed; the guidance warns that this can require more review and may slow or prevent approval.
Test real scenarios and supported surfaces
Run the server, tools, authentication, and any UI through realistic positive and negative scenarios. OpenAI calls for reliable desktop and mobile behavior. Microsoft evaluates functionality, endpoint behavior, authentication, security, compliance, telemetry readiness, and responsible AI considerations. Keep test inputs, expected behavior, and observed results tied to the version you submit.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Turn unclear feedback into a reproducible fix
Do not guess at the cause or resubmit unchanged. OpenAI says its feedback identifies unsuccessful checks and allows rejected publishers to resubmit or appeal by replying with a rationale and new information. Autodesk directs publishers to resolve identified issues and resubmit. A useful internal record lets you connect a vague decision to an exact version and a specific correction:
Quick Recap
- Freeze the submission record. Save the submitted build or release identifier and the exact listing, manifest, tool declarations, and metadata snapshot sent for review. OpenAI describes its scanned metadata as a stored, versioned API contract, so a later deployment may not alter the snapshot reviewers evaluated.
- Capture the failure context. Preserve the exact rejection text, timestamps, endpoint response, test prompts and outputs, and the credentials and authentication steps used for review.
- Map each feedback item to a check. Compare it with eligibility, endpoint reachability, authentication, package completeness, declarations, safety and privacy, and functional behavior. Reproduce the issue before changing anything.
- Make and record a targeted correction. Note the defect, the change, and the result of retesting. Verify that the deployed endpoint and the materials in the resubmission describe the same version.
- Resubmit or appeal through the target’s process. Include a concise explanation of what changed and relevant new evidence. For an appeal, OpenAI’s guidance says to reply with a rationale and new information.
Final pre-flight checklist
- Destination: I identified the exact directory or certification path and checked its current requirements.
- Publisher: The intended publisher is verified and meets the platform’s eligibility rules; endpoint ownership or control is clear where required.
- Endpoint and access: The production endpoint is reachable externally, the submitted URL is concrete and correct, and reviewer authentication works without an inaccessible step.
- Package: Required fields, files, URLs, demo materials, test cases, and policy or support pages are present and within that platform’s limits.
- Declarations: Tool descriptions, annotations, permissions, domains, and manifest entries match deployed behavior.
- Evidence: Realistic scenarios work on supported surfaces, and the submitted version and metadata are recorded for troubleshooting.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
