Background
After PR #94, `validateMcpb` rejects unsafe `entry_point` strings via the schema. But the existence check (`existsSync(join(tempDir, entry_point))`) doesn't verify:
- The path is a regular file (could be a directory)
- The file is appropriate for `server.type` (e.g., a `server.type: "node"` bundle pointing at `main.py` is logically broken)
Proposed checks
- `statSync(...).isFile()` — `entry_point` must be a regular file
- Type-aware extension hints (warning, not error):
- `node`: `.js`, `.cjs`, `.mjs`
- `python`: `.py`, or module path with no extension (e.g., `mcp_echo.server`)
- `binary`: any (must also be executable per Unix mode bits)
- `uv`: same as python
The type-aware check is a soft hint; some Python bundles use module-style entry points like `mcp_echo.server` which have no extension.
Open design question
Returning soft warnings means extending `McpbValidationResult` from a binary success/failure to a tri-state (or adding a `warnings: string[]` field on success). Worth discussing before implementation.
Acceptance criteria
- `validateMcpb` rejects bundles whose `entry_point` is a directory
- Tests in `validate.test.ts` cover the directory case
- Type-extension mismatch produces a warning (or design alternative agreed on the issue)
Background
After PR #94, `validateMcpb` rejects unsafe `entry_point` strings via the schema. But the existence check (`existsSync(join(tempDir, entry_point))`) doesn't verify:
Proposed checks
The type-aware check is a soft hint; some Python bundles use module-style entry points like `mcp_echo.server` which have no extension.
Open design question
Returning soft warnings means extending `McpbValidationResult` from a binary success/failure to a tri-state (or adding a `warnings: string[]` field on success). Worth discussing before implementation.
Acceptance criteria