Why Your MCP Listing Gets Rejected (and How to Fix It Before Submit)

Launchpad Lint by Skillfoundry · April 2026

You built a working MCP server and submitted it to a registry. Then nothing happened. Or you got a terse rejection with no detail. Or your listing appeared but buried so deep it gets zero traffic.

Most of these problems trace back to the same small set of metadata errors. Here are the ones we see most often, and how to fix each one.

1. Missing or empty homepage field

This is the single most common rejection trigger. Registries treat the homepage field in server.json as a signal that your project is maintained and reachable. If it's missing, empty, or points to a 404, many registries will silently deprioritize or reject your listing.

Fix: Set homepage to a URL that actually resolves. A GitHub repo URL is fine. A dedicated landing page is better. The URL must return a 200.

{
  "name": "my-mcp-server",
  "homepage": "https://github.com/yourname/my-mcp-server"
}

2. Description too short or too generic

A one-word or single-phrase description ("A server", "MCP tools") gets flagged by automated quality checks. Registries use your description for search ranking and listing previews. A weak description means bad discoverability even if your listing is accepted.

Fix: Write 1-2 sentences that say what your server does for the user. Not what it is — what problem it solves. Aim for 50-150 characters.

// Bad
"description": "MCP server"

// Good
"description": "Audit MCP server metadata against marketplace listing requirements before you submit."

3. Invalid or missing version

Version must be valid semver. Formats like 1.0 (no patch), v1.0.0 (leading v), or latest are all invalid. Some registries accept them but display them incorrectly; others reject outright.

Fix: Use strict semver: MAJOR.MINOR.PATCH. No prefix, no suffix unless it's a valid pre-release tag.

4. smithery.yaml config schema errors

If you're publishing to Smithery and your server accepts configuration, the configSchema in smithery.yaml must be valid JSON Schema. Common mistakes:

Using required: true on a property instead of a top-level required array
Missing type on properties
Referencing $ref paths that don't resolve

Fix: Validate your schema with any JSON Schema validator. The schema needs to be valid Draft-07 or later.

5. Slug conflicts and naming issues

Package names that contain uppercase letters, spaces, or special characters outside of hyphens will fail slug generation on most registries. Less obvious: your desired name might already be taken by a different package, in which case you get a silent collision or a confusing error.

Fix: Use lowercase-hyphenated names. Check the registry's existing listings before choosing your name.

Catch these automatically

All five of these errors are mechanical — they can be detected before you submit. Preflight checks your server package against live registry rules and tells you exactly what's wrong.

For a deeper audit that covers marketplace positioning, trust signals, and submission strategy, Launch Compliance Intelligence provides an expert manual review.

Audit your listing with Preflight