Register MCP reference servers in the official MCP Registry

[olaservo]

Description

This PR adds infrastructure to automatically register and update 7 MCP reference servers in the official MCP Server Registry. It includes:

1. server.json files for all 7 local servers (everything, filesystem, memory, sequentialthinking, fetch, git, time)
2. Version sync in release.py to keep server.json versions aligned with package versions
3. CI automation to publish server metadata to the registry after npm/pypi releases

Closes #3047

Server Details

• Servers: everything, filesystem, memory, sequentialthinking, fetch, git, time
• Changes to: Build/release infrastructure (no changes to server functionality)

Motivation and Context

The MCP Server Registry is now the official way to discover MCP servers. This PR registers the reference servers so they appear in the registry and stay updated automatically with each release.

Key benefits:

• Reference servers become discoverable via the official registry
• Versions stay in sync automatically (no manual publishing needed)
• Uses GitHub OIDC authentication (no secrets required)

How Has This Been Tested?

• server.json files validated against the registry schema
• release.py changes tested locally to verify version sync logic
• CI workflow syntax validated

Full end-to-end testing requires merging and triggering a release to verify OIDC authentication with the registry.

Breaking Changes

None. This is additive infrastructure that doesn't affect existing server functionality or user configurations.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

Files Added

src/everything/server.json
src/filesystem/server.json
src/memory/server.json
src/sequentialthinking/server.json
src/fetch/server.json
src/git/server.json
src/time/server.json

Files Modified

scripts/release.py          # Added update_server_json() method
.github/workflows/release.yml  # Added publish-registry-npm and publish-registry-pypi jobs

CI Workflow

publish-npm  →  publish-registry-npm  ─┐
                                       ├→ create-release
publish-pypi →  publish-registry-pypi ─┘

Out of Scope

The docs remote server (modelcontextprotocol.io/mcp) is not included in this PR and can be tracked separately here: modelcontextprotocol/modelcontextprotocol#2046

[Mind-Vault-AI]

f

[cliffhall]

@claude review

[claude]

Claude finished @cliffhall's task in 2m 11s —— View job

---

Code Review

• Gather context and understand the request
• Read changed files
• Review server.json files
• Review release.py changes
• Review CI workflow changes
• Post final review

---

Overall this is a well-structured PR that cleanly integrates the reference servers into the MCP Registry. The approach (OIDC auth, no secrets required, automatic version sync) is sound. A few items worth addressing before merge:

---

Security: Binary download without checksum verification

.github/workflows/release.yml lines 226-227 and 265-267

curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_linux_amd64.tar.gz" | tar xz mcp-publisher

Downloading and immediately executing an untrusted binary without hash verification is a supply chain risk. If the upstream release is compromised or the download is intercepted (despite HTTPS), malicious code would run in the release pipeline with id-token: write permissions (which can be used to impersonate the repo for OIDC).

Suggested fix: pin to a specific version and verify a checksum, e.g.:

VERSION="v0.1.2"  # pin exact version
curl -L "https://github.com/modelcontextprotocol/registry/releases/download/${VERSION}/mcp-publisher_linux_amd64.tar.gz" -o mcp-publisher.tar.gz
echo "expected_sha256  mcp-publisher.tar.gz" | sha256sum -c
tar xz -f mcp-publisher.tar.gz mcp-publisher

Fix this →

---

Logic: Matrix-level success gate skips successful registrations

.github/workflows/release.yml lines 198 and 238

if: ${{ needs.publish-npm.result == 'success' }}

publish-npm and publish-pypi are matrix jobs with fail-fast: false. If even one package in the matrix fails to publish, the overall job result is 'failure', so publish-registry-npm/publish-registry-pypi are skipped for all packages — including ones that published successfully.

This is probably not the desired behavior. If server-memory publishes successfully but server-everything fails, server-memory should still be registered. One approach is to use result != 'cancelled' and let the inner check for server.json step handle no-ops, or check each package individually using a different job structure.

---

Code quality: Duplicate update_server_json method

scripts/release.py lines 80-97 and 124-141

NpmPackage.update_server_json and PyPiPackage.update_server_json are byte-for-byte identical. Since both classes implement the Package protocol, this logic could live in a standalone function called by both:

def _update_server_json(path: Path, version: Version) -> None:
    server_json_path = path / "server.json"
    if not server_json_path.exists():
        return
    with open(server_json_path, "r") as f:
        data = json.load(f)
    data["version"] = version
    for package in data.get("packages", []):
        package["version"] = version
    with open(server_json_path, "w") as f:
        json.dump(data, f, indent=2)
        f.write("\n")

Fix this →

---

server.json: SSE transport in everything is deprecated

src/everything/server.json lines 22-27

{
  "registryType": "npm",
  "identifier": "@modelcontextprotocol/server-everything",
  "version": "0.0.0",
  "runtimeHint": "npx",
  "packageArguments": ["sse"],
  "transport": { "type": "sse" }
}

Per the project guidelines, SSE is a deprecated transport. Advertising it in the registry for new users discovering the server may not be ideal. Consider removing this entry or adding a note (if the schema supports it).

---

server.json: Placeholder versions vs. actual published versions

All server.json files use "version": "0.0.0" while the servers are already published at real versions (0.6.x, 2.0.0 for server-everything). This is fine architecturally since update_server_json in release.py will sync on the next release cycle, but the registry will show stale 0.0.0 entries until code changes trigger a release for each server. You may want to either:

• Pre-populate with the current versions before merging, or
• Document that a manual trigger or a dummy change is needed to kick off initial registration

---

Minor: filesystem/server.json missing packageArguments

src/filesystem/server.json

The filesystem server requires at least one directory path argument to function (npx @modelcontextprotocol/server-filesystem /path/to/dir). Without a packageArguments hint or environment/installInstructions (if the schema supports those), users discovering the server via the registry may find it non-obvious. Consider adding a placeholder or documenting this in the description.

---

Summary

Severity	Issue
🔴 Security	Binary downloaded without checksum verification (release.yml)
🟡 Logic	Matrix failure gates entire registry publish job
🟡 Code quality	update_server_json duplicated in NpmPackage and PyPiPackage
🟢 Informational	SSE transport in everything/server.json is deprecated
🟢 Informational	Placeholder 0.0.0 versions need a first-publish trigger
🟢 Informational	filesystem/server.json lacks argument hints for end users

The security item should be addressed before merging given the pipeline has OIDC token write permissions. The logic issue is worth a follow-up or at minimum a comment in the workflow explaining the tradeoff.