The MCP Launch Compliance Checklist You Didn't Know You Needed
Launch Compliance by Skillfoundry · April 2026
Your MCP server works. Your tests pass. Your README is clean. But when you submit to a registry, the review process checks things that have nothing to do with whether your code runs.
Registries care about trust. They care about discoverability. They care about whether users who install your server will have a good experience. That means they check a layer of compliance that most builders never think about until their listing is rejected or buried.
Here's the checklist.
Metadata completeness
server.json has name, description (50+ chars), version (valid semver), and homepage (resolves to 200)
Package name is lowercase-hyphenated, unique on target registry
smithery.yaml (if targeting Smithery) has valid startCommand and configSchema
README.md exists and explains what the server does, how to install, and how to configure
Trust signals
Registries increasingly weigh trust signals when ranking listings. These aren't always explicit requirements, but their absence affects your visibility:
License field: Present and set to a recognized SPDX identifier. Unlicensed servers are deprioritized in most registries.
Repository URL: Points to a public repo. Registries check that it exists and is accessible.
Author or maintainer field: A named maintainer signals accountability. Anonymous packages rank lower.
Changelog or release history: Shows the server is actively maintained. A single commit with no history is a weak signal.
Runtime packaging
Entry point works from a clean install: npm install && npm start (or equivalent) must succeed without manual setup steps, local secrets, or environment-specific paths.
No hardcoded secrets or local paths: Registries scan for .env references, hardcoded API keys, and absolute filesystem paths. Even if they don't reject on this, automated security scanners flag it.
Dockerfile (if applicable) builds in CI: If your server ships a Dockerfile, it must build without local context. Smithery builds from source — a Dockerfile that assumes local volumes or host networking will fail.
Configuration schema
Valid JSON Schema for any user-facing configuration. Not a type description — actual JSON Schema that a UI can render.
Sensible defaults for optional fields. A config schema with 15 required fields and no defaults creates a terrible onboarding experience.
Documented environment variables if the server reads from process.env. Undocumented env vars are invisible to registry UIs.
Registry-specific rules
Each registry has quirks:
Smithery: Requires smithery.yaml. Builds from source. Config schema must be valid or the listing page breaks.
AgenticMarket: Description length limits. Tag structure matters for category placement. Homepage field is prominently displayed.
npm MCP registry: Standard npm publishing rules apply. Scoped packages (@org/name) need organization access. Version conflicts block publish.
The gap between "it works" and "it's ready"
Most MCP builders are strong on the code side. The compliance gap is in the packaging, metadata, and trust layer — the things registries check that have nothing to do with whether your tools work.
Automated tools like Preflight catch the mechanical issues: missing fields, invalid schemas, broken URLs. For the full picture — trust signals, positioning, registry-specific strategy — a manual compliance review covers what automation can't reach.