How to submit an MCP server to ToolHive registry

This is the most selective of the GitHub-hosted lists. It publishes a written bar, scores entries against it, and has a core team member review every pull request^[1][2]. So the work is not mainly the file. It is deciding, honestly, whether your project clears the bar before you write the file.

What the registry requires

Copyleft licences such as AGPL-3.0, GPL and LGPL are excluded. Entries are either Official, meaning maintained by the ToolHive team, the MCP specification authors or the platform owners, or Community, which is where yours would sit^[3][2].

The file

An entry is a server.json in the upstream MCP format, in its own folder under registries/toolhive/servers/. It is either container-based, with a packages list, or remote, with remotes^[4]. ToolHive's own fields go in _meta.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.stacklok/my-remote-server",
  "description": "What your server does in one sentence",
  "repository": { "url": "https://github.com/myorg/my-server", "source": "github" },
  "version": "1.0.0",
  "remotes": [{ "type": "streamable-http", "url": "https://api.example.com/mcp" }],
  "_meta": {
    "io.modelcontextprotocol.registry/publisher-provided": {
      "io.github.stacklok": {
        "https://api.example.com/mcp": { "tier": "Community", "status": "Active", "tools": ["tool_name_1"] }
      }
    }
  }
}

• The key inside _meta must match the package identifier for a container, or the remote URL for a remote server^[4].
• Folder names use lowercase letters and hyphens^[4].

From fork to merge

1. Open an issue outlining what you are adding, then fork the repository^[1].
2. Sign off every commit with a Signed-off-by trailer, which is the Developer Certificate of Origin^[1].
3. Run task catalog:validate^[2].
4. Open the pull request. CI must pass, a core team member reviews it, and commits are squashed into one with your pull request title^[1].

Why a submission is declined

What the criteria rule out

• A thin client or a repository with only packaging files, for a third-party server. The implementation itself must be open source. An official vendor's own server may sit on a proprietary backend^[2].
• A copyleft licence, or a missing one. If the licence is unclear, they ask you to clarify^[2].
• Actions pinned to a tag and not a commit SHA, or unpinned dependencies^[3].

What counts against you

The criteria weigh organic signals and list patterns of manufactured traction: stars that do not match watchers or forks, one account with many near-empty repositories created in a short window, and a history of mostly automated or marketing commits. A cluster of those, with a single maintainer and no real adoption, is grounds to decline until the project shows sustained community health^[2]. A repository only days or weeks old with little adoption is a yellow flag, as is no release in six months^[2].

By hand

Read both criteria documents against your repository first, fix what they flag, and then do the four steps above. Expect a human reading your project and not only a validator.

Current status, 1 Oct 2026

On 2 Oct 2026 the repository had 30 open pull requests and 6 open issues^[5]. The criteria documents and the README quoted here were the current versions on main^[2][4].