The workflow at a glance
Choose between a remote MCP connector and a GitHub-hosted plugin bundle, then prepare pinned inputs, expected results, permission descriptions and a fixed version. Submission, approval and publication are separate states. An installable package or successful automatic check does not establish a live directory listing.
Separate the official announcement from our checklist
The official portal announcement and September 25 release notes describe access for developers on paid Claude plans, submission of a remote MCP connector or GitHub bundle of MCP servers and skills, validation and review feedback, publication after approval, and usage analytics once live.
The following preparation steps are editorial recommendations, not a complete statement of official review criteria or a promise of acceptance. Verify support in the intended product surface. A component supported in Claude Code does not automatically work in every Claude entry point.
| Path | Announced entry | Suggested evidence |
|---|---|---|
| Single MCP connector | Point to a remote MCP server | Address, operations, example input/output and access instructions |
| Plugin bundle | GitHub-hosted MCP and skills package | Pinned commit, structure, installation, dependencies and repeatable example |
| Existing listing | Existing skills, connectors and plugins need no change because of this announcement | Check the current listing before creating a new version |
Original case: draft a support handoff
Imagine a fictional support-handoff plugin that reads an authorized sample ticket and produces a draft containing the issue, known facts, missing information and proposed next action. It neither updates real tickets nor sends mail. Another reviewer can compare its input and output without relying on the author’s explanation. No plugin submission or paid-account test was performed for this article.
Ticket T-021 reports an upload failure but supplies no browser version, reproduction steps or attachment. The expected result preserves these unknowns. A formatted answer saying that browser incompatibility was confirmed or a refund completed would fail the exercise.
Make the demonstration independently checkable
T-021: user reports upload failure; no browser version, reproduction steps, attachment or refund record.
Issue: upload failure. Known: user report only. Missing: version, steps, attachment. Next action: draft a request for information, pending human approval.
Turn personal knowledge into handoff material
Pin a release or commit and describe installation, configuration placeholders and the entry point. Keep real credentials out of sample files. For an external connection, explain who supplies a test account, what is read, which actions exist and what should happen after access is revoked. Preparing this description does not require purchasing an account first.
Add unsuccessful cases: missing authorization, empty input, absent fields and an unavailable remote service. Describe the visible error and actions that must not occur. A failed read must not become a claim that no tickets exist. This exposes boundaries that a successful screenshot cannot show.
Submission preparation package
- One fixed version with matching installation instructions.
- Fictional repeatable input, expected points and a human comparison method.
- Accurate read/write scope, distinguishing drafts from sending.
- Placeholder configuration with no real credentials in code or screenshots.
- Recorded behavior for missing fields, access and service failures.
- Named product surfaces and checked versions without universal compatibility claims.
Ask someone else to follow the instructions
Give the package to a reviewer who did not implement it. Check whether they can reproduce T-021’s facts and missing fields, and whether they understand the draft needs human approval. Record every point that requires an unspoken explanation; those are documentation gaps.
The Claude Docs review-to-handoff guide offers a related way to distinguish states, while a collaborative document remains a different deliverable. Apply the document prompt-injection checks when ticket content tries to override instructions or obtain account information. Treat source text as data rather than authorization.
Reproduce the T-021 summary using only the package. Record version, product entry, exact input, known facts and missing information in the output. Check whether any external write occurs. Do not claim refunded or sent without evidence. Keep authorization and service errors distinct from empty data. List instructions that the author still needs to supply.Keep evidence for every release state
Do not describe a package as listed before verifying its actual state. Save feedback with the revision that addresses it. After approval, check publication separately through the portal and the real user entry. An approval screenshot alone cannot establish discoverability.
After release, investigate which surface and version fail and whether dependencies are explained. Analytics can guide maintenance, but installations and listing discovery do not establish successful user tasks or organic website traffic.
Evidence follows the state
- Preparing
Pin material
Version, example, expected result and scope are ready.
- Submitted
Retain feedback
Save the submitted object and checks without claiming approval.
- Approved
Schedule publication
Preserve approval and decide when to publish.
- Published
Inspect the listing
Verify the actual user entry and track versions and feedback.
Recheck the scope when capabilities change
Adding ticket writeback to a read-only summarizer changes its permissions and acceptance questions. Update the description and rerun both the fixed example and failure cases. Preserve earlier version records rather than reusing a demonstration name to imply a fix.
This workflow establishes preparation and handoff evidence. Directory acceptance, account eligibility and regional availability remain product and review decisions. Our checking date is October 15, 2026; the original announcement remains dated September 25.
Common questions
Can a free Claude account use this submission portal?
The September 25 announcement describes access for developers on paid plans. Check your actual account entry rather than assuming equivalent eligibility for a free account.
Does automatic validation mean the plugin is listed?
No. Check review and approval separately. The announcement says developers decide when to publish after approval; verify the real listing before announcing availability.
Must an existing listed skill immediately become a plugin?
The announcement says existing directory skills, connectors and plugins need no change because of it. Check current needs before creating a duplicate release.
