mcp publish: support MCPB server.type "uv"

[prakharagarwal-dev]

Problem

smithery mcp publish rejects a valid MCPB v0.4 bundle whose manifest uses the standard server.type: uv runtime.

Command:

smithery mcp publish ./linkedin-mcp-server-0.14.1.mcpb -n prakharagarwal3031/linkedin-mcp-server

Result with Smithery CLI 1.2.0:

Could not determine bundle runtime from manifest

The same unpacked manifest passes @anthropic-ai/mcpb@2.1.2 validate. MCPB documents uv as a supported v0.4 runtime for Python projects with pyproject.toml and a lockfile.

Cause

detectBundleRuntime() currently recognizes only python, node, binary, and a bun command. It does not recognize manifest.server.type === uv.

Reproduction artifact

• Release bundle: https://github.com/prakharagarwal-dev/linkedin-mcp-server/releases/download/v0.14.1/linkedin-mcp-server-0.14.1.mcpb
• Manifest source: https://github.com/prakharagarwal-dev/linkedin-mcp-server/blob/v0.14.1/packaging/mcpb/manifest.json
• Bundle SHA-256: 309c694f8560bd41c27d564f58b2a2dca314cadbb96212f2fac8ddd02d292d64
• Release checksums and GitHub attestations: https://github.com/prakharagarwal-dev/linkedin-mcp-server/releases/tag/v0.14.1

Requested behavior

Please recognize the MCPB uv runtime and provision/execute it according to the MCPB manifest contract. Treating this bundle as traditional python is not a portable workaround because its dependencies are intentionally resolved by uv rather than vendored into the archive.

[TheWhiteWater]

Confirmed with a second independent self-hosted MCP while preparing TheWhiteWater/tube-bridge v1.1.4 for Smithery.

• @anthropic-ai/mcpb@2.1.2 validate accepts the v0.4 manifest with server.type: "uv".
• The unpacked bundle starts via uv run --locked, completes MCP initialize, exposes all 17 tools, and returns typed tool errors correctly.
• smithery@1.2.0 mcp publish ... fails with Could not determine bundle runtime from manifest.
• The current Smithery OpenAPI StdioDeployPayload.runtime enum also contains only node | binary | python | bun, so this appears to require an API contract/runtime addition as well as the CLI detectBundleRuntime() case.

Relabeling the bundle as traditional python is not a safe workaround: the official MCPB UV runtime is what provides cross-platform dependency resolution for compiled Python dependencies. We are preserving the self-hosted boundary rather than replacing it with a hosted URL solely to bypass this limitation.