|
| 1 | +# Smithery stdio packaging: problem domain and handoff |
| 2 | + |
| 3 | +## Audience |
| 4 | +This document is for a new AI agent with no context about the prior investigation. |
| 5 | + |
| 6 | +## Original problem |
| 7 | +XcodeBuildMCP is a **local stdio** MCP server deployed via the Smithery CLI. The server depends on bundled non-code assets (e.g., `bundled/` with an `axe` binary and frameworks). When deploying with the Smithery CLI, the resulting `.mcpb` bundle **does not include** these bundled assets, so the installed server lacks required resources at runtime. |
| 8 | + |
| 9 | +## Key facts about the current Smithery CLI (v3.x) |
| 10 | +The Smithery CLI now builds and packs local stdio servers by: |
| 11 | +1) Building the stdio bundle into an output directory (default `.smithery/stdio`). |
| 12 | +2) Packing only that output directory into `server.mcpb` using `@anthropic-ai/mcpb`. |
| 13 | +3) Uploading the `server.mcpb` in `smithery deploy --transport stdio`. |
| 14 | + |
| 15 | +Important constraints: |
| 16 | +- The CLI **does not read `smithery.config.js`** or run any custom build hooks for asset staging. |
| 17 | +- The CLI only reads `smithery.yaml` for metadata (e.g., name/target), not for a prepack step. |
| 18 | +- The pack step includes only what is inside `.smithery/stdio`. |
| 19 | + |
| 20 | +## What we did |
| 21 | +1) Confirmed the repository uses `@smithery/cli` v3.x and targets a local stdio server. |
| 22 | +2) Verified that `smithery build --transport stdio` produces `.smithery/stdio/server.mcpb` **without** `bundled/`. |
| 23 | +3) Confirmed that the previous `smithery.config.js` copy approach is obsolete because the CLI no longer loads that config. |
| 24 | +4) Opened a Smithery CLI issue to request an official asset-staging hook: |
| 25 | + - https://github.com/smithery-ai/cli/issues/524 |
| 26 | + |
| 27 | +## How to reproduce the missing-assets behavior |
| 28 | +From the XcodeBuildMCP repo: |
| 29 | +1) `npx smithery build --transport stdio -o .smithery/stdio` |
| 30 | +2) `unzip -l .smithery/stdio/server.mcpb` |
| 31 | + - The bundle contains the compiled entrypoint and manifests only. |
| 32 | + - `bundled/` is missing. |
| 33 | + |
| 34 | +## Workaround (local validation only) |
| 35 | +This is **not** compatible with `smithery deploy`, but it proves the bundle can contain assets: |
| 36 | +1) Build the stdio bundle: |
| 37 | + - `npx smithery build --transport stdio -o .smithery/stdio` |
| 38 | +2) Copy assets into the stdio output directory: |
| 39 | + - `cp -R bundled .smithery/stdio/bundled` |
| 40 | +3) Temporarily replace `manifest.json` with `mcpb-manifest.json` for packing: |
| 41 | + - `cp .smithery/stdio/manifest.json .smithery/stdio/manifest.payload.json` |
| 42 | + - `cp .smithery/stdio/mcpb-manifest.json .smithery/stdio/manifest.json` |
| 43 | +4) Re-pack using the official `mcpb` CLI: |
| 44 | + - `npx @anthropic-ai/mcpb pack .smithery/stdio .smithery/stdio/server.mcpb` |
| 45 | +5) Restore the original manifest: |
| 46 | + - `mv .smithery/stdio/manifest.payload.json .smithery/stdio/manifest.json` |
| 47 | + |
| 48 | +Result: `server.mcpb` now contains `bundled/` and its frameworks. |
| 49 | + |
| 50 | +## Why the workaround cannot be used for deployment |
| 51 | +`smithery deploy --transport stdio` rebuilds and repacks in its own flow, and provides no prepack hook to stage assets. As a result, there is no official way to inject `bundled/` into the `.mcpb` during deploy. |
| 52 | + |
| 53 | +## How we likely want to proceed |
| 54 | +### Option A: Upstream fix (recommended) |
| 55 | +Add an official asset staging hook or prepack command in the Smithery CLI: |
| 56 | +- Example: `smithery.yaml` fields like `build.assets` or `build.prepackCommand`. |
| 57 | +- The hook should run before `packExtension()` in `src/lib/bundle/stdio.ts`. |
| 58 | +- This would allow asset copying into `.smithery/stdio` during `smithery deploy`. |
| 59 | + |
| 60 | +Issue to track: |
| 61 | +- https://github.com/smithery-ai/cli/issues/524 |
| 62 | + |
| 63 | +### Option B: Fork the CLI |
| 64 | +If the upstream fix is slow, fork `smithery-ai/cli` and add: |
| 65 | +- A prepack hook (env var or `smithery.yaml` field). |
| 66 | +- A deterministic asset staging step inside `buildStdioBundle` before the pack step. |
| 67 | +Then consume the fork in CI: |
| 68 | +- Publish the fork under a scoped npm package, or |
| 69 | +- Install the fork from GitHub release in the release workflow. |
| 70 | + |
| 71 | +Current implementation (forked CLI): |
| 72 | +- Added `build.prepackCommand` support in `smithery.yaml` (plus env var overrides). |
| 73 | +- CI/release workflows install the forked CLI before `smithery build`. |
| 74 | +- This repo wires `smithery.yaml` to `scripts/smithery-prepack.sh` to bundle/copy assets. |
| 75 | + |
| 76 | +## Current repo state that matters |
| 77 | +- `smithery.config.js` exists but is **ignored** by v3.x CLI. |
| 78 | + - Any asset copy logic in this file does not run in deploy. |
| 79 | +- Release workflow currently publishes npm and MCP registry, but **does not** run Smithery deploy. |
| 80 | +- `npm run build` uses Smithery’s default transport (shttp) unless explicit `--transport stdio` is used. |
| 81 | + |
| 82 | +## Summary |
| 83 | +The problem is not an outdated CLI version. The CLI is current, but the integration strategy is obsolete because v3.x no longer honors `smithery.config.js`. The deploy flow packs only `.smithery/stdio`. Until Smithery adds an official prepack/assets hook (or a fork is used), correct bundling for local stdio deployments is not achievable via `smithery deploy`. |
0 commit comments