MCP Server List

Submit to Smithery

Publish an eligible public remote MCP endpoint through Smithery’s release API, then verify its scan and current server connection.

Publish a public unauthenticated remote release and follow its scan. Eligibility is checked before purchase.

Remote API publication and release trackingSources checked

What to prepare

  • A public HTTPS Streamable HTTP endpoint with explicitly declared unauthenticated access for the initial adapter.
  • An owned Smithery namespace/server name and a connected credential with the required read/publishing access.
  • Passing global MCP endpoint checks and a name without a conflicting existing publication.

Match the publishing path to the actual artifact

Smithery documents URL-based publication and local MCPB bundles. MCP Server List’s initial execution path covers public unauthenticated remote endpoints only. A repository containing stdio source is not a reviewed bundle and cannot be sold through this adapter.

Keep the transport, endpoint and owner namespace accurate in the saved profile. The free preflight checks the connected Smithery account and existing identity before you approve the public release payload. A conflicting server name is a blocker, not an invitation to replace another publication.

Follow the release rather than assuming the scan passed

The publishing API accepts a release asynchronously and returns its real identifier. The worker records that reference and polls the provider’s release state. Queued or working releases remain submitted; authentication pauses, scan failures and unexpected identity changes stay visible.

A successful release is checked against both the planned upstream endpoint and the current published server connection. This matters because a platform gateway URL can stay unchanged while the underlying release changes. An accepted API request alone does not establish a live listing.

Resolve readiness before spending

Check that a fresh client can initialize the exact HTTPS endpoint and list the intended capabilities. Network protection, authentication requirements and required configuration can prevent provider scanning even when your own logged-in client works.

Smithery documents OAuth and static server-card options for broader publishing scenarios. Those capabilities do not imply this service has validated every such combination. Unsupported authenticated scanning remains blocked until an execution path can check its actual prerequisites.

Submission workflow

  1. Save the exact public endpoint, auth_type none and owned smithery_name.
  2. Run free preflight to verify the connected namespace and check for an existing or conflicting release.
  3. Review the immutable public payload and authorize the launch; verified payment queues the API publication.
  4. Follow the actual release ID through scanning. A successful release must match the currently published server connection before listed is reported.

Blockers to resolve before review

Use these as preparation checks. The destination makes its own acceptance decision.

  • A hosted endpoint does not implement the required transport or cannot be reached over HTTPS.
  • Authentication or network protection prevents the scanner from discovering the server.
  • A bundle is missing required files or the displayed capabilities do not match the current release.

Primary sources

Checked 2026-10-29. Follow the destination’s current instructions if its requirements change.

← Compare all destinations