[Aymericr]

What does this PR do?

Agent integrations now take their versions from the package versions instead of hardcoding them, and server.json is ready for the official MCP Registry under a reverse-DNS name. Nothing publishes automatically.

• One source of truth. scripts/sync-agent-versions.ts rewrites every @pascal-app/cli@<version> quote (both Cursor mcp.json configs and the three setup docs) from packages/cli/package.json, and the server.json version from packages/mcp/package.json. --check runs in bun run skills:validate, so CI fails on drift. scripts/cursor-plugin-policy.ts reads the expected pin from the CLI package instead of hardcoding 1.0.0. The pin moves from 1.0.0 to the published 1.0.4.
• Betas keep the last stable version. A beta release commits to main, so a naive sync would pin Cursor marketplace installs and server.json to a prerelease. While the packages are on a prerelease, the sync leaves integrations alone, and the Cursor policy and the registry workflow accept the last stable pin, which must still be an exact stable version.
• server.json (schema 2025-12-11, the current one) is renamed from io.github.pascalorg/editor to app.pascal/editor. It lists the npm package @pascal-app/mcp (stdio, npx) next to the remote https://editor.pascal.app/api/mcp (streamable-http), and its version is the package version, 1.0.4. I removed the remote's required Authorization: Bearer sk_live_… header: the endpoint advertises OAuth through its 401 WWW-Authenticate: … resource_metadata=… challenge, and the Cursor plugin already uses OAuth only. API keys still work as a bearer token. packages/mcp/package.json gains "mcpName": "app.pascal/editor", which the registry needs to verify npm ownership.
• Release/CI. In the bump step, release.yml runs the sync after bun install (before any publish), so the release commit's git add -A carries the new pin and manifest. It then runs mcp-publisher validate. There is no registry publish step. On PRs, mcp-registry.yml also checks server.json against packages/mcp/package.json (version, mcpName, package entry) and checks that the endpoint returns the OAuth challenge. The live API-catalog and server-card checks are in a separate hosted-matches-manifest job gated on if: github.event_name == 'workflow_dispatch', so it is skipped on PRs and pushes and cannot block PR CI. It is the gate to run by hand before publishing.
• Docs. wiki/npm-release.md has a new MCP Registry section with the manual publish steps (DNS or HTTP auth for pascal.app, mcp-publisher publish). README.md and skills/README.md are updated to match.

Publishing audit

Only release.yml publishes (npm, GitHub release asset, GHCR image), and it is workflow_dispatch-only, as before. ci.yml, mcp-ci.yml, docker.yml (builds without pushing) and mcp-registry.yml publish nothing. Nothing in this repo runs mcp-publisher publish.

Outside this repo

• Hosted card and catalog (pascalorg/private-editor). Done in private-editor [Deps] mcp: MCP SDK 2.3.1 and @hono/node-server 1.19.17 (security) #1119 and deployed. /.well-known/mcp/server-card.json reports serverInfo.version: "1.0.4", and /.well-known/api-catalog reports app.pascal/editor 1.0.4. I ran the hosted-matches-manifest steps against production with bash -e, and both pass.
• Namespace auth for app.pascal/*. This needs a pascal.app DNS TXT record (v=MCPv1; k=ed25519; p=…) or https://pascal.app/.well-known/mcp-registry-auth for mcp-publisher login dns|http.
• npm mcpName. The published @pascal-app/mcp@1.0.4 has no mcpName, so the registry will reject a publish until the next stable release, which carries it.
• Registry history. io.github.pascalorg/editor 0.6.1 stays in the registry. After app.pascal/editor is published, an owner can mark the old entry deprecated with mcp-publisher status.
• Cursor marketplace. The bundle's CLI pin changed, but plugin.json stays at 0.1.10. If the marketplace refresh needs a new bundle version, bump the plugin version separately.

CI note

The first quality run on this branch failed in packages/mcp/src/tools/author-scene.test.ts, with an unhandled error from three-bvh-csg require()-ing ESM three. That failure came from main (#1107), not this branch, and main has since fixed it ("Use the ESM CSG entry point in server-side geometry compilation"). This branch now includes that fix through a merge of main.

How to test

1. Run bun scripts/sync-agent-versions.ts --check. It exits 0.
2. Set packages/cli/package.json and packages/mcp/package.json to 1.0.5, then run bun scripts/sync-agent-versions.ts. Both Cursor configs, the three docs and server.json now say 1.0.5, and bun run skills:validate passes. Set them to 1.0.5-beta.1 instead: nothing changes and validation still passes. Revert.
3. Run mcp-publisher validate (v1.8.1) from the repo root. It prints ✅ server.json is valid.
4. Run MCP Registry by hand (gh workflow run mcp-registry.yml). hosted-matches-manifest passes against production.

Checks I ran locally on the final head: bun run check, bun run skills:validate (75 pass), bun run check-types (13/13), mcp-publisher validate, the simulated stable release above, and the validate and hosted-matches-manifest job steps against production under bash -e (all pass, including the beta and drift cases for the manifest check).

Screenshots / screen recording

N/A — non-visual change

Checklist

• I've tested this locally with bun dev
• My code follows the existing code style (run bun check to verify)
• I've updated relevant documentation (if applicable)
• This PR targets the main branch

  

---

Note

Low Risk
Mostly tooling, manifests, and CI; hosted auth is documented as OAuth discovery rather than manifest headers, with no automatic registry publish.

^{Reviewed by Cursor Bugbot for commit a6ab970. Bugbot is set up for automated code reviews on this repo. Configure here.}