server.json: missing CI validation + mcpb-pack version consistency checks

[shwetank-dev]

Problem

There are two related gaps in how server.json is handled across the build pipeline:

1. server.json existence is not checked in CI

server.json is required for MCP registry discovery. Without it, a server is installable via mpak but not discoverable. Currently nothing in CI catches a missing or malformed server.json — a PR can be submitted, reviewed, and merged without it, and the problem only surfaces at release time when mcpb-pack runs.

Location	Checks existence?	Validates fields?
ci.yml	No	No
scan.yml	No	No
build-bundle.yml	Partial — skips silently if missing	No
mcpb-pack action	Yes	Only name + description

2. mcpb-pack does not verify consistency between server.json and manifest.json

mcpb-pack validates that server.json has name and description fields, but does not check that they are consistent with manifest.json. It simply overwrites server.json.version from manifest.json rather than validating they already match. The following are never checked:

• server.json.name matches manifest.json.name
• server.json.description matches manifest.json.description
• server.json.version matches manifest.json.version before release

This means a server could ship with a server.json that describes a completely different package and nothing would catch it.

---

Proposed Solution

Phase 1: Fix in CI/CD (developer repos + template)

Add a validate-server-json step to ci.yml that runs on every PR:

#!/bin/bash
set -e

# 1. Check existence
if [ ! -f server.json ]; then
  echo "ERROR: server.json is missing — required for MCP registry discovery"
  exit 1
fi

# 2. Validate required fields
NAME=$(jq -r '.name // empty' server.json)
DESC=$(jq -r '.description // empty' server.json)

if [ -z "$NAME" ]; then
  echo "ERROR: server.json missing required field: name"
  exit 1
fi

if [ -z "$DESC" ]; then
  echo "ERROR: server.json missing required field: description"
  exit 1
fi

# 3. Check consistency with manifest.json
MANIFEST_NAME=$(jq -r '.name' manifest.json)
MANIFEST_VERSION=$(jq -r '.version' manifest.json)
SERVER_VERSION=$(jq -r '.version // empty' server.json)

if [ "$NAME" != "$MANIFEST_NAME" ]; then
  echo "MISMATCH: server.json.name '$NAME' != manifest.json.name '$MANIFEST_NAME'"
  exit 1
fi

if [ -n "$SERVER_VERSION" ] && [ "$SERVER_VERSION" != "$MANIFEST_VERSION" ]; then
  echo "MISMATCH: server.json.version '$SERVER_VERSION' != manifest.json.version '$MANIFEST_VERSION'"
  echo "Run: make bump"
  exit 1
fi

echo "OK: server.json is valid and consistent with manifest.json"

Add to ci.yml:

- name: Validate server.json
  run: bash scripts/validate-server-json.sh

Phase 2: Strengthen mcpb-pack

Once CI validation is proven, add the same consistency checks to mcpb-pack as a hard gate at release time:

• Fail if server.json is missing (currently it silently skips)
• Fail if server.json.name does not match manifest.json.name
• Fail if server.json.version does not match manifest.json.version before overwriting

---

Additional Consideration: Generate server.json from make bump

Rather than maintaining server.json manually, make bump could generate or update it from manifest.json, ensuring name, description, and version are always in sync by construction:

bump:
	$(eval VERSION := $(shell cat .PACKAGE_VERSION))
	# ... update other files ...
	@jq --arg v "$(VERSION)" \
	    --arg name "$$(jq -r '.name' manifest.json)" \
	    --arg desc "$$(jq -r '.description' manifest.json)" \
	    '.version = $$v | .name = $$name | .description = $$desc' \
	    server.json > server.tmp.json && mv server.tmp.json server.json
	@echo "server.json updated."

This means server.json only needs title and repository set manually — everything else is derived from manifest.json automatically.

---

Affected repos

• NimbleBrainInc/mcp-server-template — add scripts/validate-server-json.sh and CI step (Phase 1)
• NimbleBrainInc/mcpb-pack — strengthen validation (Phase 2)
• All existing server repos — add server.json if missing, add validation script on next PR

Related

• Version Management: Multiple Sources of Truth Across MCP Servers #16 — Version management: multiple sources of truth across MCP servers