[jo-adithya]

Summary

• Produce v4-only custom-plugin manifests, including signed registration metadata, credential schemas, and governance validation.
• Require a signed manifest and let the SDK supply specVersion automatically.
• Update the generated template, examples, migration docs, and tests; retain chained-auth utilities for standalone hosts.

Stack

Part 1 of 2. Merge this PR before the structured tool outputs and cancellation PR, which targets this branch.

Verification

• Single-agent source review against main and the sibling Futurity custom-registration contracts.
• Signing tests: 8 passed.
• Standard manifest/app tests blocked locally by missing dependencies; no dependencies installed.
• Isolated type check using existing external dependencies still reports an unrelated error in unchanged derive-public.ts.
• Coverage gap: credential-schema rules, signed metadata preservation, and automatic specVersion in the served signed manifest need dedicated regression tests.

Compatibility

Breaking SDK API change: legacy manifest versions and chained custom-registration manifests are rejected; pluginManifest is required.

[alexng353]

is this version meant to be separable from the mcp({ version })?

[jo-adithya]

I was following the examples from futurity-marketplace repo

[jo-adithya]

This is the example for esb in futurity-marketplace

[alexng353]

[agent] Review at 947cf90. Eight independent reads (correctness, contract, premise, simplification; two models each). bun test 164/164 and type-check pass. Platform integration was not run.

Must-fix: the SDK signs manifests Futurity rejects. The SDK accepts a non-empty credentials_schema on authorization_code (pluginManifest.ts:273-313), and accepts the reserved credential keys grant_type, data_api_params and token_request_params (:80). Futurity #1409 rejects both (apps/api/src/routes/mcp/lib/plugin-registration.ts:68-72, :96-100). So a developer gets a validly signed manifest that registration then refuses. All six non-simplification reads hit this, with reproductions. Mirror both rules here and add a test for each.

Should-fix

• Version. The public API breaks, but package.json stays at 2.0.0 and the template still depends on ^2.0.0. This needs 3.0.0.
• PluginManifestOptions uses the parsed output type, so fields with defaults become required for callers. That's why examples/monday fails with TS2322. Use z.input, and type-check the examples in CI.
• The new validation rules aren't tested. Deleting whole validation blocks leaves the suite green. Each rule needs a test that fails without it.
• Dataset fields is optional in the type but required at runtime (:198 vs :224). Make them agree.

Nit: the nested grant ternary at :288-296 reads better as a lookup table from grant to required keys. Equivalence was checked on 2,204 generated manifests.

Note: bun install --frozen-lockfile fails because bun.lock is out of date. That predates this stack, but is worth fixing while you're here.

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com