Define the release someone can actually use
Start with a release, not a list of destinations. Write down the source repository, package or hosted endpoint, transport, version, and owner. If these disagree, a directory can import a convincing description while pointing a user at software they cannot run.
Use an installable package when users should run your server locally. Use a remote endpoint when you operate the server. For a project supporting both, test both paths and make the choice clear in your README. Do not claim compatibility with a client until you have completed that client’s connection and a representative operation.
- Local: exact package identifier and version, runtime requirement, launch command, arguments, and environment variable names.
- Remote: exact MCP URL, transport, authentication route, account prerequisites, and a safe first operation.
- Ownership: maintainer identity, repository access, license, support route, and any verified registry name.
Run a fresh-environment installation
A successful run inside your development checkout can depend on uncommitted files, globally installed tools, or a cached token. Start from the instructions you intend to publish in a fresh shell or disposable environment. Install the released artifact, not a locally linked package.
Use the official MCP Inspector to connect, list capabilities, and exercise a safe example. The command below demonstrates the shape for a built local server; replace the path with the artifact your user will run. The current Inspector documentation requires Node 22.19.0 or newer. Pin a reviewed Inspector version in repeatable CI.
# First build your server using its documented instructions.
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
# Inspect the returned schemas before calling any tool.
# Keep production credentials out of shared logs and screenshots.Write the installation contract in the README
Document the minimum configuration needed for a first successful call. Separate required credentials from optional features. For every variable, explain what it controls, where the user gets it, and whether an empty value is allowed. Examples should contain placeholders; a directory brief should never carry a reusable secret.
Explain the boundary between read and write tools in ordinary language. A user connecting a calendar server should be able to tell whether it can only read events or can also invite attendees. Tool annotations are helpful hints, but your server must still enforce authorization.
- A one-sentence description naming the task and underlying system.
- Copyable installation or connection instructions and a minimal configuration example.
- A safe sample input with expected result shape, plus common authentication and startup errors.
- License, maintenance contact, and supported version or release policy.
Separate a diagnostic from complete eligibility
The anonymous repository check helps find missing or inconsistent public preparation details. Its score does not certify runtime behavior or predict a maintainer’s decision. Read the individual messages and keep evidence from your own clean installation test.
Full MCP Server List preflight requires an account, a saved profile and the applicable owner connections. It checks global ownership and protocol prerequisites together with every selected destination’s rules. The report contains exact proposed public payloads, evidence, blockers and remedies. A failed requirement or unavailable worker blocks payment rather than becoming a paid checklist.
Approve the exact set before execution
Different targets require different actions: structured registry publication, an API release, a checked contribution PR, a maintainer intake request or downstream ingestion verification. Choose only routes your server and the currently available integrations can actually execute. Catalog presence does not establish eligibility.
Review every target and payload in the free immutable report. After the owner authorizes that scope, create an unpaid draft bound to the preflight. The fixed service fee starts its jobs automatically after verified payment; the customer does not need to submit each job separately.
- Ready: published mechanical requirements passed for the checked profile and connections.
- Blocked or unavailable: resolve the prerequisite or remove the target before purchase.
- Submitted: the provider accepted a real release, PR or intake action.
- Listed: matching provider evidence establishes the expected public record; discretionary approval remains separate from readiness.
Sources and scope
Primary documentation checked 2026-10-29. The workflow advice is MCP Server List’s editorial guidance; each destination controls its own current requirements and review.