When server.type is "binary", mcpb pack now ensures the entry_point
file has execute bits (|0o111) in the ZIP external_attr, regardless
of the source filesystem permissions. This prevents EACCES failures
when Claude Desktop extracts Windows-built binary MCPBs (which store
644 because Windows has no Unix execute bit).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
platform_overrides.*.env was replacing the entire mcp_config.env object
instead of merging, causing base env vars (including ${user_config.*}
references) to be silently dropped when platform overrides defined any
env vars.
Fixes#217
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add three pre-pack validators to catch common runtime failures early:
- validateEntryPoint: checks file exists, extension matches server type,
binary has executable bit (Unix)
- validateCommandVariables: scans mcp_config for unrecognized ${...}
variables against the runtime allowlist
- validateSensitiveFiles: warns about credentials.json, *.pem, *.key,
.ssh/, etc. that would be bundled
validateManifest() now accepts optional { projectDir } to separate the
manifest directory from the source file directory.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Allow specifying an external manifest file path with `mcpb pack --manifest <path>`.
The manifest resolves relative to CWD, is validated, injected into the bundle,
and errors immediately if the specified file is not found.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- hello-world-node: wrap server startup in async main() with proper
await on server.connect(transport) — fixes crash on initialize in
Claude Desktop UtilityProcess runtime (closes#200)
- hello-world-uv: add required mcp_config block — v0.4 schema requires
it but the example omitted it, causing mcpb pack to fail
- file-manager-python: convert from broken v0.1/python to v0.4/uv —
the old manifest had privacy_policies on v0.1 (schema violation),
used command "python" (ENOENT on macOS), and had no bundled deps.
Now uses UV runtime with proper mcp_config (closes#47, closes#72)
- Graduate UV runtime from experimental across docs and schema comments
- Bump DEFAULT_MANIFEST_VERSION from 0.2 to 0.3
All three examples verified: pack succeeds, server responds to MCP
initialize over stdio, tools/list returns expected tools.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The signMcpbFile function appended a signature block to the ZIP file but
did not update the EOCD comment_length field. Strict ZIP parsers (like
Claude Desktop's) rejected these files because the declared comment
length didn't account for the appended signature data.
Now scans backwards for the EOCD magic bytes, reads the current
comment_length, and adds the signature block length before concatenating.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Break function parameters onto separate lines with trailing comma.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Allow developers to specify which manifest version to use when
initializing a new manifest.json file.
Usage: mcpb init --manifest-version 0.3
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add UV as a new server type for Python extensions that use UV runtime
for dependency management instead of bundling dependencies.
Schema changes (v0.4):
- Add "uv" to server.type enum
- Make mcp_config optional (not needed for UV type)
- UV extensions rely on pyproject.toml for dependencies
Documentation:
- Add UV runtime section to MANIFEST.md explaining benefits and usage
- Update README.md to recommend UV runtime for Python
- Add complete hello-world-uv example
Benefits of UV runtime:
- Cross-platform support (Windows/macOS/Linux, Intel/ARM)
- Small bundle size (~100 KB vs 5-10 MB)
- Handles compiled dependencies portably
- No user Python installation required
Example manifest:
{
"manifest_version": "0.4",
"server": {
"type": "uv",
"entry_point": "src/server.py"
}
}
Co-authored-by: Joan <joan@anthropic.com>
- Export McpbManifestAny and Logger types from types.js
- Export McpbSignatureInfo and McpbUserConfigValues from shared/common.ts
- Add exports to both main and browser entry points
- Bump version to 2.0.1
This eliminates the need for manual type inference in consuming code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The localization parameter is commented out in the buildManifest function
signature, so it should also be commented out in the test calls.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The buildManifest function signature has the localization parameter
commented out (expecting 13 params), but the function call was still
passing it as the 14th argument, causing a type error.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed all entry points (index.ts, cli.ts, node.ts) to export from schemas/index.js
instead of schemas/0.3.js. This provides access to all versioned schemas (v0_1, v0_2,
v0_3, vAny) and VERSIONED_MANIFEST_SCHEMAS without exposing a specific version.
The build script was still importing from the deleted schemas/latest.js file.
Updated to import McpbSignatureInfoSchema from 0.3.js and removed the
mcpb-manifest-latest entry from versionedManifestSchemas.
Changes:
- Create McpbManifestDefault type derived from VERSIONED_MANIFEST_SCHEMAS[DEFAULT_MANIFEST_VERSION]
- Update init.ts to use McpbManifestDefault instead of hardcoded v0.2 schema
- Import schema types from version matching DEFAULT_MANIFEST_VERSION (0.2)
- Update test to match commented-out localization field
- Make McpbManifest (deprecated) point to McpbManifestDefault
This makes the codebase more maintainable by deriving types from DEFAULT_MANIFEST_VERSION instead of hardcoding version references.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Export LATEST_MANIFEST_VERSION to indicate the maximum supported manifest version by the vAny schema. This allows clients to know what the highest version is that they can use.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Change McpbManifest type to point to v0.2 schema instead of McpbManifestAny
- Add DEFAULT_MANIFEST_VERSION export to browser.ts
- Update test fixtures to use manifest_version "0.2" when using McpbManifest type
- Keep @deprecated annotation directing users to McpbManifestAny for multi-version support
This maintains backwards compatibility for existing code using McpbManifest while encouraging new code to use McpbManifestAny for broader version support.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Remove the concept of "vLatest" throughout the codebase to encourage use of McpbManifestAny which supports all manifest versions. Changes include:
- Delete src/schemas/latest.ts and src/schemas_loose/latest.ts
- Remove vLatest and latest-related exports from schema index files
- Remove McpbManifestLatest type, replace McpbManifest to point to McpbManifestAny
- Remove LATEST_MANIFEST_VERSION, LATEST_MANIFEST_SCHEMA constants
- Update all main export files (index.ts, cli.ts, node.ts) to export from 0.3.js instead of latest.js
- Update tests to use v0_3.McpbManifestSchema explicitly
- Add @deprecated annotation to McpbManifest directing users to McpbManifestAny
This encourages better version compatibility by using the union type that supports all manifest versions rather than assuming a single "latest" version.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed return type to use the specific v0.2 manifest schema type since the
function returns a manifest with DEFAULT_MANIFEST_VERSION (0.2).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
