Apply proper type distinction:
- Reading/validating existing manifests: Use McpbManifest (any version)
- Building/creating new manifests: Use McpbManifestLatest (latest only)
Changes:
- src/shared/config.ts: Revert to McpbManifest for config operations
- src/cli/init.ts: Use McpbManifestLatest for new manifest creation
- test/config.test.ts: Use McpbManifest for testing config operations
This ensures backward compatibility when reading existing manifests
while enforcing latest schema for new builds.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Update manifest type usage in config and packaging to strictly enforce
the latest schema version (0.3) instead of accepting any version.
Changes:
- src/shared/config.ts: Use McpbManifestLatest instead of McpbManifest
- src/types.ts: Add McpbManifestLatest type export
- test/config.test.ts: Update tests to use McpbManifestLatest
This ensures BUILD manifests are validated against the latest schema
only during packaging, preventing use of older schema versions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove duplicate node:path import in test/icon-validation.test.ts
- Replace 4 instances of 'any' type with 'unknown' in error handlers
- Auto-format code with prettier (27 formatting fixes)
Addresses review feedback from PR #136
All 6 errors and 27 warnings resolved
Reverted the discriminated union type change. McpbManifest now uses
the latest schema as before. Consumers can use versioned schemas
directly if they need to validate specific versions.
Changed McpbManifest type from a single version to a discriminated union
of all historical manifest versions (0.1, 0.2, 0.3).
This allows the type system to properly handle manifests from any version
while maintaining type safety through the manifest_version/dxt_version
discriminator field.
Benefits:
- Type-safe handling of multiple manifest versions
- TypeScript can narrow types based on version field
- No need for type assertions when working with versioned manifests
- Maintains backward compatibility with all historical versions
Implements icon validation to catch common issues that prevent icons from
displaying in Claude Desktop. Uses a non-blocking warning approach for
remote URLs to maintain flexibility for MCPB's evolving multi-platform
ecosystem.
## Changes
### Core Implementation (src/node/validate.ts)
- Add `isPNG()` helper to validate PNG file signatures via magic bytes
- Add `validateIcon()` function with comprehensive checks:
- **Warn** about remote URLs (non-blocking, best practice guidance)
- **Reject** ${__dirname} variable usage in icon field (doesn't work)
- **Reject** absolute paths (not portable)
- Verify icon file exists at specified path
- Verify icon file is valid PNG format
- Recommend 512×512 size for Claude Desktop
- Integrate icon validation into `validateManifest()` after schema validation
### Test Coverage
- Update `test/icon-validation.test.ts` - Remote URL test now expects warning
- Update `test/cli.test.ts` - Integration test updated for warnings
- All 109 tests passing
### Documentation Updates
- Update examples/hello-world-node/manifest.json to v0.3
## Validation Behavior
**Remote URLs (WARNING - non-blocking):**
```
Icon path uses a remote URL. Best practice for local MCP servers:
Use local files like "icon": "icon.png" for maximum compatibility.
Claude Desktop currently only supports local icon files in bundles.
```
**Result:** Validation passes, developer is informed
**Other Issues (ERROR - blocking):**
- ${__dirname} usage: Rejects (doesn't work)
- Absolute paths: Rejects (not portable)
- Missing files: Rejects (broken reference)
- Non-PNG files: Rejects (wrong format)
## Rationale
**Non-Blocking Approach:**
- Doesn't prevent valid bundles from being created
- Educates developers about best practices
- Maintains flexibility as MCPB evolves beyond Claude Desktop
- Future-proof if remote URL support is added
**Still Protective:**
- Blocks truly broken configurations (missing files, wrong formats)
- Provides actionable error messages for fixable issues
Based on real-world findings from investigating icon display issues in
Claude Desktop with production MCPB bundles.
- Rename CURRENT_MANIFEST_VERSION to LATEST_MANIFEST_VERSION
- Rename CURRENT_MANIFEST_SCHEMA to LATEST_MANIFEST_SCHEMA
- Rename CURRENT_MANIFEST_SCHEMA_LOOSE to LATEST_MANIFEST_SCHEMA_LOOSE
- Update all references throughout codebase and tests
- Add schemas/latest.ts and schemas_loose/latest.ts as aliases to current version
- Update constants.ts to use latest.ts instead of hardcoded version imports
- This makes version updates easier - only need to update latest.ts pointer
- Create src/schemas.ts to re-export from schemas/index.ts for test imports
- Update test manifests to use manifest_version "0.2" instead of "1.0" or "1.0.0"
- Fix import sorting and formatting issues in schema files
- Export McpbManifestSchema from schemas/index.ts
- Move schemas.ts and schemas-loose.ts into separate versioned folders
- Create schemas/0.1.ts and schemas/0.2.ts for strict validation
- Create schemas_loose/0.1.ts and schemas_loose/0.2.ts for loose validation
- Add index files to export all historical schema versions
- Update all imports to use schemas/0.2.ts
- Enforce exact version values using z.literal() for both v0.1 and v0.2
- Remove dxt_version support from v0.2 schemas
- Remove all passthrough() from v0.2 strict schemas
- Validate privacy_policies as URLs in v0.2
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add validation to ensure the manifest_version matches the current expected
version (0.2) during the mcpb pack command. This prevents users from
packing extensions with outdated or incorrect manifest versions.
Changes:
- Add CURRENT_MANIFEST_VERSION constant to centralize version management
- Validate manifest version in pack command before creating bundle
- Update init command to use version constant
- Update tests to use version constant
- Fix prettier formatting issues
Add optional privacy_policies array field to manifest.json that allows
developers to declare their data handling practices. This field accepts
an array of privacy policy statements that describe how the extension
collects, uses, and protects user data.
- Update manifest schema to include privacy_policies field
- Add empty privacy_policies array to all example manifests
- Document the new field in MANIFEST.md
- Replace manifest_version with $schema field pointing to official schema URL
- Support backward compatibility with legacy dxt_version field
- Update all examples and tests to use new $schema field
- Mark dxt_version as deprecated but still functional
- Require either $schema or dxt_version (at least one must be present)
* fix: prevent zip slip attacks in DXT unpack function
Add path validation to prevent directory traversal attacks when unpacking DXT files.
The fix validates that extracted file paths remain within the intended output directory
before writing files to disk.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix: make zip slip protection cross-platform compatible
Use path.sep instead of hardcoded '/' separator to ensure path validation
works correctly on both Windows and Unix systems. This fixes failing tests
on Windows while maintaining security protection against directory traversal.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* feat: add clean command to clean manifest and trip dev deps for node
* fix: lazy import no loop
* Update src/cli/cli.ts
Co-authored-by: Felix Rieseberg <f@anthropic.com>
---------
Co-authored-by: Felix Rieseberg <f@anthropic.com>
