Guard the MCP Registry entry in CI and document republishing [sc-146582] - #4
Conversation
Publishing server.json to the registry is a manual step that only lives in one person's shell history, and the first attempt failed on a schema limit that nothing checked for. Automating it in CI would mean storing the ifttt.com Ed25519 signing key as an Actions secret. This repository is public, and the com.ifttt namespace authenticates by domain rather than through GitHub, so there is no keyless way to publish from here — publishing stays a manual maintainer step, run from the key in 1Password. What CI can do without the key is catch the mistakes before they reach a publish attempt: server.json's description now fails validation past the registry's 100-character cap, and version must be semver. CONTRIBUTING.md documents the entry, the manual publish sequence, and why the key is deliberately not in CI.
8d38668 to
1373247
Compare
ssathy2
changed the title
📝 WalkthroughWalkthroughThe change adds MCP Registry contribution guidance and extends manifest validation for description length and SemVer-compliant versions. ChangesMCP Registry validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish-mcp.yml:
- Around line 18-20: Add workflow-level concurrency configuration for the
publish workflow, using a stable group and setting cancel-in-progress to false.
Place it alongside the top-level workflow settings so all publish jobs are
serialized while queued runs remain available to complete.
- Around line 44-47: Update the “Install mcp-publisher” workflow step to use a
tested, pinned release URL instead of releases/latest. Download the archive to a
file, verify its SHA-256 checksum or Sigstore bundle against the trusted release
metadata, and extract mcp-publisher only after verification succeeds.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: IFTTT/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b60a5946-4e2c-4a6f-b010-49bbe5cc669a
📒 Files selected for processing (3)
.github/workflows/publish-mcp.ymlAGENTS.mdCONTRIBUTING.md
| jobs: | ||
| publish: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Serialize registry publication runs.
If concurrent runs can publish the same registry version, define a workflow-level concurrency group with cancel-in-progress: false. Otherwise, competing runs can issue publication requests for an immutable version, causing one run to fail after another run publishes it.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish-mcp.yml around lines 18 - 20, Add workflow-level
concurrency configuration for the publish workflow, using a stable group and
setting cancel-in-progress to false. Place it alongside the top-level workflow
settings so all publish jobs are serialized while queued runs remain available
to complete.
| - name: Install mcp-publisher | ||
| if: steps.check.outputs.changed == 'true' | ||
| run: | | ||
| curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
cat -n .github/workflows/publish-mcp.yml | sed -n '1,100p'
printf '%s\n' '--- related publisher references ---'
rg -n --hidden -S 'mcp-publisher|modelcontextprotocol/registry|releases/latest|sha256|sigstore|cosign' .github README.md 2>/dev/null || true
printf '%s\n' '--- repository status ---'
git status --shortRepository: IFTTT/ifttt-plugins
Length of output: 303
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- workflow files ---'
git ls-files '.github/workflows/*' || true
printf '%s\n' '--- matching files and references ---'
fd -HI 'publish-mcp|mcp|workflow' .github . 2>/dev/null | head -200 || true
rg -n --hidden -S 'mcp-publisher|modelcontextprotocol/registry|releases/latest' . 2>/dev/null | head -200 || true
printf '%s\n' '--- repository metadata ---'
git remote -v || true
git branch --show-current || true
git rev-parse HEAD || trueRepository: IFTTT/ifttt-plugins
Length of output: 1741
🌐 Web query:
Model Context Protocol registry mcp-publisher GitHub releases SHA256 checksum Sigstore verification artifacts
💡 Result:
The mcp-publisher command-line tool, used for interacting with the Model Context Protocol (MCP) registry, provides signed artifacts for its releases on GitHub [1][2][3]. Users can verify these releases using SHA256 checksums and Sigstore-based provenance verification [4][5]. Release Artifacts For each release, the official repository provides the following assets: - Compressed binaries (e.g., mcp-publisher_linux_amd64.tar.gz) [1][2]. - Software Bill of Materials (SBOM) in JSON format (e.g., *.sbom.json) [1][2]. - Sigstore bundles in JSON format (e.g., .sigstore.json) [1][2]. - A checksum file for the release (e.g., registry_vX.Y.Z_checksums.txt) [1][2]. Verification Procedures Security-conscious workflows typically pin both the version and the SHA256 digest of the binary [4][5]. 1. SHA256 Verification: The checksum file provided in the release contains the hash for the binaries. This can be verified using standard tools: sha256sum -c registry_vX.Y.Z_checksums.txt [4][5] 2. Sigstore Provenance Verification: The Sigstore bundle (.sigstore.json) allows for verifying that the artifact was produced by the official GitHub Actions workflow. Verification is performed using the Cosign CLI: cosign verify-blob \ --bundle mcp-publisher.tar.gz.sigstore.json \ --certificate-identity "https://github.com/modelcontextprotocol/registry/.github/workflows/release.yml@refs/tags/vX.Y.Z" \ --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \ mcp-publisher.tar.gz [4][5] Additional Notes - Artifacts: The official MCP Registry hosts only server metadata (in server.json), not the actual server artifacts themselves [6][7]. - Integrity Hashes: For server packages (e.g.,.mcpb files), authors are responsible for generating SHA256 hashes to be included in their server.json, which MCP clients then use to validate file integrity upon installation [7]. - Tool Usage: The mcp-publisher tool itself is installed via pre-built binaries or Homebrew and is used to validate and publish metadata to the registry [8][3].
Citations:
- 1: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.1
- 2: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.9
- 3: https://modelcontextprotocol.info/tools/registry/cli/
- 4: https://github.com/IronSecCo/ironclaw/blob/main/runbooks/mcp-registry.md
- 5: https://github.com/jmrplens/libgen-mcp/blob/7f672657dcf95a663c2dc1fe141c2c0a20672d7f/.github/workflows/release.yml
- 6: https://modelcontextprotocol.io/registry/quickstart
- 7: https://modelcontextprotocol.info/tools/registry/publishing/
- 8: https://github.com/modelcontextprotocol/registry/blob/HEAD/docs/modelcontextprotocol-io/quickstart.mdx
🏁 Script executed:
#!/bin/bash
set -eu
api='https://api.github.com/repos/modelcontextprotocol/registry'
printf '%s\n' '--- latest release ---'
curl -fsSL "$api/releases/latest" |
jq '{tag_name, name, assets: [.assets[] | {name, size, browser_download_url}]}'
printf '%s\n' '--- recent release tags ---'
curl -fsSL "$api/releases?per_page=5" |
jq -r '.[] | [.tag_name, .name] | `@tsv`'Repository: IFTTT/ifttt-plugins
Length of output: 306
🌐 Web query:
site:github.com/modelcontextprotocol/registry/releases mcp-publisher checksums sigstore.json
💡 Result:
In the context of the Model Context Protocol (MCP) registry and mcp-publisher releases, the.sigstore.json files associated with each release artifact are cryptographic signatures used to verify the integrity and provenance of the software [1][2]. When you download a release asset, such as mcp-publisher_linux_amd64.tar.gz, there is a corresponding.sigstore.json file provided alongside it [1][3]. These files are generated using Sigstore, a project that provides tools for signing and verifying software artifacts to ensure they have not been tampered with [1][2]. To verify an artifact, you would typically use the Sigstore verification tools (such as cosign) to check the signature against the public transparency log, using the information contained within the.sigstore.json file [1][4]. Similarly, the registry releases include a checksums.txt file, which also has a corresponding.sigstore.json file, allowing for the verification of the entire checksum file itself [1][5]. By including these files in every release, the project enables automated security verification, allowing users to confirm that the downloaded binary matches the official build produced by the project's CI/CD pipeline [1][3][6].
Citations:
- 1: https://github.com/modelcontextprotocol/registry/releases/tag/v1.8.0
- 2: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.9
- 3: https://github.com/modelcontextprotocol/registry/releases/tag/v1.4.1
- 4: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.7
- 5: https://github.com/modelcontextprotocol/registry/releases/tag/v1.4.0
- 6: https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.6
Pin and verify the publisher binary.
Replace releases/latest with a tested release. Download the archive, verify its SHA-256 checksum or Sigstore bundle, and extract it only after verification.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish-mcp.yml around lines 44 - 47, Update the “Install
mcp-publisher” workflow step to use a tested, pinned release URL instead of
releases/latest. Download the archive to a file, verify its SHA-256 checksum or
Sigstore bundle against the trusted release metadata, and extract mcp-publisher
only after verification succeeds.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/validate.mjs`:
- Around line 334-336: Update CONTRIBUTING.md to document that server.json
version values must use SemVer, including the repository’s stricter local
validation despite the MCP Registry schema permitting non-SemVer values. Place
this guidance alongside the existing OpenClaw skill frontmatter SemVer policy.
- Around line 328-332: Update the description-length validation to count Unicode
code points with Array.from(manifest.description).length for both the
100-character comparison and the error message, instead of using
manifest.description.length.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: IFTTT/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 5a0ba46a-c439-46bc-87e3-45d8c4b87de7
📒 Files selected for processing (2)
CONTRIBUTING.mdscripts/validate.mjs
🚧 Files skipped from review as they are similar to previous changes (1)
- CONTRIBUTING.md
| if (typeof manifest.description === "string" && manifest.description.length > 100) { | ||
| addError( | ||
| `server.json "description" is ${manifest.description.length} characters; the registry schema caps it at 100.`, | ||
| ); | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
node <<'NODE'
const description = "😀".repeat(100);
const codePoints = Array.from(description).length;
if (description.length !== 200 || codePoints !== 100) {
throw new Error(`Unexpected counts: ${description.length}/${codePoints}`);
}
console.log({ codeUnits: description.length, codePoints });
NODERepository: IFTTT/ifttt-plugins
Length of output: 193
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- validator context ---'
sed -n '300,345p' scripts/validate.mjs
printf '%s\n' '--- description schema references ---'
rg -n -C 3 '"description"|maxLength|server\.schema|2025-12-11' . \
-g '!node_modules' -g '!dist' -g '!build' | head -200
printf '%s\n' '--- referenced schema ---'
curl -fsSL https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json |
node -e '
let data = "";
process.stdin.on("data", chunk => data += chunk);
process.stdin.on("end", () => {
const schema = JSON.parse(data);
console.log(JSON.stringify({
description: schema.properties?.description,
serverDescription: schema.properties?.server?.properties?.description
}, null, 2));
});
'Repository: IFTTT/ifttt-plugins
Length of output: 5425
🏁 Script executed:
#!/bin/bash
set -euo pipefail
curl -fsSL https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json |
python3 -c '
import json, sys
schema = json.load(sys.stdin)
def walk(value, path=()):
if isinstance(value, dict):
if "maxLength" in value or "description" in value:
print(json.dumps({"path": ".".join(path), "value": value}, ensure_ascii=False))
for key, child in value.items():
walk(child, path + (str(key),))
elif isinstance(value, list):
for index, child in enumerate(value):
walk(child, path + (str(index),))
walk(schema)
'Repository: IFTTT/ifttt-plugins
Length of output: 30025
🌐 Web query:
JSON Schema validation maxLength Unicode code points UTF-16 code units official specification
💡 Result:
In the official JSON Schema specification, the validation keywords maxLength and minLength are defined based on the number of Unicode code points in a string [1][2][3]. While older drafts of the specification referred to the "number of its characters" as defined by relevant IETF RFCs for JSON (such as RFC 8259) [4][5][6], current specifications explicitly clarify this as the count of Unicode code points [1]. It is important to note that this is distinct from UTF-16 code units [7]. Because many programming environments (such as JavaScript/Node.js) count length by UTF-16 code units, a discrepancy can arise when handling characters outside the Basic Multilingual Plane (BMP), such as certain emojis or complex symbols [7]. For example, a single character consisting of a surrogate pair in UTF-16 counts as two code units but only one Unicode code point [7]. Consequently, developers should be aware that implementation-specific string length properties—often based on UTF-16 code units—may not align with the JSON Schema requirement of counting Unicode code points [7].
Citations:
- 1: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/jsonschema-validation.md
- 2: https://www.learnjsonschema.com/draft7/validation/maxlength/
- 3: https://www.learnjsonschema.com/2020-12/validation/maxlength/
- 4: https://json-schema.github.io/json-schema/latest/json-schema-validation.html
- 5: https://json-schema.org/draft-07/json-schema-validation
- 6: https://json-schema.org/draft/2020-12/json-schema-validation
- 7: Schema.isMaxLength uses UTF-16 code units but emits JSON Schema maxLength Effect-TS/effect#6336
Count Unicode code points for the 100-character cap.
String.prototype.length counts UTF-16 code units. Use Array.from(manifest.description).length for both the comparison and the error message.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/validate.mjs` around lines 328 - 332, Update the description-length
validation to count Unicode code points with
Array.from(manifest.description).length for both the 100-character comparison
and the error message, instead of using manifest.description.length.
| if (typeof manifest.version === "string" && !semverPattern.test(manifest.version)) { | ||
| addError(`server.json "version" ("${manifest.version}") must be semver (e.g. 1.0.0).`); | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
schema_url='https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json'
curl -fsSL "$schema_url" |
jq -e '.definitions.ServerDetail.properties.version.description
| contains("Non-semantic versions are allowed")'Repository: IFTTT/ifttt-plugins
Length of output: 162
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- validator context ---'
sed -n '300,355p' scripts/validate.mjs
printf '%s\n' '--- repository policy references ---'
rg -n -i --glob '!node_modules' --glob '!dist' \
'semver|semantic version|non-semantic|version.*policy|version.*format|contribut|server\.json' \
README.md CONTRIBUTING.md .github scripts package.json 2>/dev/null || true
printf '%s\n' '--- version declarations and validator usage ---'
rg -n --glob '!node_modules' \
'"version"\s*:|semverPattern|manifest\.version|validate\.mjs' . 2>/dev/null | head -250Repository: IFTTT/ifttt-plugins
Length of output: 6703
Document the server.json SemVer policy.
CONTRIBUTING.md documents SemVer for OpenClaw skill frontmatter but not for server.json. The validator rejects non-SemVer versions, while the MCP Registry schema permits them. Document this repository-specific requirement and the stricter local validation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/validate.mjs` around lines 334 - 336, Update CONTRIBUTING.md to
document that server.json version values must use SemVer, including the
repository’s stricter local validation despite the MCP Registry schema
permitting non-SemVer values. Place this guidance alongside the existing
OpenClaw skill frontmatter SemVer policy.
1 participant
Problem
Publishing
server.jsonto the official MCP Registry is a manual sequence that only exists in one person's shell history. The first attempt also failed on a schema limit — the registry capsdescriptionat 100 characters and ours was ~200 — which nothing in the repo checked for.Why not automate it
The obvious fix is a workflow that republishes on version bumps. That requires storing the ifttt.com Ed25519 signing key as an Actions secret, and this repository is public. The
com.iftttnamespace authenticates by proving domain ownership rather than through GitHub (login github-oidconly grantsio.github.*names), so there is no keyless path to publishing from CI. Publishing stays a manual maintainer step, run from the key in 1Password.What this does instead
CI can still catch the failures before someone attempts a publish, with no secret involved:
server.jsonnow fails validation ifdescriptionexceeds the registry's 100-character cap, or ifversionisn't semver. Both slot into the existingvalidateRegistryManifest()inscripts/validate.mjs— offline, no new dependency.CONTRIBUTING.mddocuments the registry entry, the manual publish sequence, and why the key is deliberately kept out of CI.Validation
node scripts/validate.mjspasses on the real file, and rejects a seeded 120-character description and a1.0version with the expected two errors.Story: sc-146582
Summary by CodeRabbit
Documentation
Bug Fixes