feat: add MCPB manifest + auto-build .mcpb on every release tag

[fengyat]

Why

Lays the groundwork for submitting OrcaRouter to the Anthropic Connectors Directory. The Directory needs an .mcpb (MCP Bundle) — a zip of the server + a manifest.json describing how to run it.

This PR ships the bundle wiring. The human still does the final web-form submission (Anthropic has no automated Directory submission API yet).

What's new

File	Purpose
manifest.json	MCPB spec v0.3 manifest. Server entry point, user_config block (ORCAROUTER_API_KEY field, required:false so catalog tools work without one), Privacy Policy URL (https://www.orcarouter.ai/privacy.html), MIT license, icon, tools_generated:true.
assets/logo.png	512×512 PNG (MCPB recommended size), extracted from logo.gif and resized.
scripts/build-mcpb.sh	Stages a clean bundle (dist + production node_modules + manifest + LICENSE + icon), runs mcpb pack.
package.json	New pack:mcpb script.
.github/workflows/publish-mcp.yml	Two new trailing steps: build MCPB, attach to a GitHub Release for the same tag. Requires contents: write.
.gitignore	Exclude .mcpb-stage/ and *.mcpb.

How releases work after this lands

git tag v1.1.5 && git push origin v1.1.5
  ↓ CI:
  ├─ npm publish
  ├─ mcp-publisher publish (MCP Registry)
  ├─ build .mcpb
  └─ create / update GitHub Release v1.1.5 with the .mcpb attached

Last manual step (one-time, per release): download the .mcpb from the GitHub Release and submit to https://clau.de/desktop-extention-submission to land in the Anthropic Connectors Directory.

Local verification done

• mcpb validate manifest.json — schema passes; icon at recommended 512×512
• npm run pack:mcpb → produces orcarouter-mcp-1.1.4.mcpb (3.5 MB packed, 10.7 MB unpacked, 998 files included / 1255 ignored via default .mcpbignore)
• mcpb info <bundle> reports the expected name/version
• YAML parses (python3 -c 'import yaml; yaml.safe_load(...)')

Idempotency

The Release step is idempotent: re-running the publish workflow for an existing tag uploads/replaces the .mcpb asset cleanly via gh release upload --clobber. Same rerun-safety pattern as the npm + Registry publish steps already use.

Out of scope (intentional)

• No actual Directory submission — that's a manual web form upload after the next release.
• No icon variants (light/dark, smaller sizes) — single 512×512 covers the standard case; the manifest's optional icons array can be filled in a follow-up if Claude Desktop's UI ever needs theme-aware variants.
• No CHANGELOG entry — this PR is pure release-pipeline scaffolding, no behavior change to the MCP server itself.

Test plan

• Reviewer: confirm the contents: write permission expansion on the workflow is comfortable (needed to create the Release).
• After merge: cut the next release tag (whenever) and watch the workflow attach the .mcpb to its Release.

[fengyat]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 60306129d5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[fengyat]

@codex review

Good catch — manifest.json was outside the version-drift check, so a future release tag would have shipped a stale-version bundle.

Fixed in 2206712: added `manifest.json.version` to the existing tag-vs-version validation step in publish-mcp.yml. Now the workflow validates all four version locations match the tag before doing anything destructive:

• `package.json` version
• `server.json` version
• `server.json` packages[0].version
• `manifest.json` version

Same pattern as before — the release PR is the source of truth, CI just enforces. Please take another look.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".