mcp publish rejects any .mcpb bundle that declares tools (MCPB tools schema ⊥ registry Tool schema)

[swperb]

Summary

smithery mcp publish <bundle>.mcpb fails with a 400 from the registry whenever the bundle's manifest.json declares any tools. The CLI forwards MCPB tools to the registry as MCP Tool[] (which require inputSchema), but the MCPB manifest format forbids inputSchema on tool entries — so there is no manifest that satisfies both tools. The only way to publish a bundle is to omit tools entirely.

Reproduction

manifest.json (minimal node bundle) with one tool:

{
  "manifest_version": "0.3",
  "name": "repro-tools-schema",
  "version": "0.0.1",
  "description": "Minimal repro.",
  "author": { "name": "repro" },
  "server": {
    "type": "node",
    "entry_point": "index.js",
    "mcp_config": { "command": "node", "args": ["${__dirname}/index.js"] }
  },
  "tools": [
    { "name": "do_thing", "description": "does a thing" }
  ]
}

1. mcpb pack . → succeeds.
2. smithery mcp publish ./repro.mcpb -n <ns>/repro →

Publishing <ns>/repro (stdio) to Smithery Registry...
Deployment failed: 400 {"error":"Invalid input: expected object, received undefined"}

With N tools you get the error repeated N times (...; ...; ...) — one per tool, for the missing inputSchema object.

Trying to fix it by adding inputSchema to the tool makes the other tool reject the manifest:

$ mcpb pack .
Validating manifest...
ERROR: Manifest validation failed:
  - tools.0: Unrecognized key(s) in object: 'inputSchema'
ERROR: Cannot pack extension with invalid manifest

So mcpb pack and smithery mcp publish disagree on the tool schema, and there's no manifest that passes both.

Root cause

In getBundleDeployPayload() (src/lib/mcpb.ts), the MCPB manifest's tools are forwarded onto the serverCard with a cast that papers over the type mismatch:

...(manifest.tools
  ? { tools: manifest.tools as unknown as ServerCard["tools"] }
  : {}),

MCPB tool entries are { name, description? } (the MCPB schema sets additionalProperties: false, hence the inputSchema rejection in mcpb pack). But ServerCard["tools"] is MCP Tool[], where inputSchema is a required object. The registry then validates each forwarded tool and rejects the missing inputSchema with expected object, received undefined.

Suggested fix

When mapping MCPB tools → serverCard.tools, synthesize a permissive default for the field MCPB can't carry, e.g.:

tools: manifest.tools.map(t => ({
  name: t.name,
  description: t.description,
  inputSchema: { type: "object" },   // MCPB tools can't declare this; default it
})),

This preserves the tool names/descriptions in the registry listing instead of forcing publishers to drop tools. (Alternatively: don't forward MCPB tools at all and rely on runtime introspection — but that loses the listing metadata.)

Impact

Any .mcpb bundle that documents its tools — which the MCPB format explicitly encourages — cannot be published. The failure mode is opaque (expected object, received undefined, no field name), so it's hard to diagnose without reading the CLI source. Workaround today: delete tools from the manifest before mcpb pack.

Environment

• @smithery/cli 4.11.1
• @anthropic-ai/mcpb 2.1.2
• manifest_version "0.3", node bundle, stdio

[swperb]

Related: the same bundle→registry path also drops listing metadata (description, etc.)

(Edited for precision — see note at the end.)

The tools issue isn't isolated. getBundleDeployPayload() builds a serverCard from only serverInfo (name, version) plus optional tools/prompts/resources, and a configSchema:

return {
  type: "stdio",
  runtime: detectBundleRuntime(...),
  serverCard: {
    serverInfo: { name: manifest.name, version: manifest.version },
    ...(manifest.tools ? { tools: ... } : {}),
    ...(manifest.prompts ? { prompts: manifest.prompts } : {}),
    ...(manifest.resources ? { resources: manifest.resources } : {}),
  },
  ...(configSchema ? { configSchema } : {}),
}

So the manifest's description, homepage, documentation, repository, license, and icon are never put on the payload — there's no code path that forwards them.

Confirmed for description: a bundle whose manifest.description is set still publishes with an empty listing description. The listing only got a description after I typed it by hand in the web UI — and the live text matches what I pasted, not the manifest's own description. There's no --description/--homepage CLI flag either, so a fully-populated manifest can't produce a complete listing through publish alone.

Suggested fix: forward the remaining manifest fields onto the registry record in getBundleDeployPayload() — description, homepage/documentation, repository, license, and icon (surfacing the bundled icon as iconUrl). Combined with defaulting inputSchema for tools (above), a well-formed .mcpb could then publish as a complete, high-scoring listing in one shot.

---

Edit: I originally also listed icon as empirically "dropped"; I've narrowed that — I only cleanly verified description. The serverCard shape above shows none of these fields are forwarded, but I didn't isolate each one at runtime, so I'm scoping the confirmed claim to description.

[vshulcz]

Confirming this on @smithery/cli 4.11.1 with a Go stdio server (four tools), and adding the other half of the failure, because the documented workaround does not get you to a working listing either.

With tools — as reported, 400 with one Invalid input: expected object, received undefined per tool.

Adding inputSchema to satisfy the registry — does not work. mcpb validate rejects it before packing:

- tools.0: Unrecognized key(s) in object: 'inputSchema'
- tools.1: Unrecognized key(s) in object: 'inputSchema'
- tools.2: Unrecognized key(s) in object: 'inputSchema'
- tools.3: Unrecognized key(s) in object: 'inputSchema'

So the two schemas are mutually exclusive rather than merely awkward to satisfy: there is no manifest that both mcpb validate and the registry accept.

Removing tools entirely — the suggested workaround. This gets further, then leaves a broken listing:

Publishing vshulcz/deja-vu (stdio) to Smithery Registry...
✓ Created server "vshulcz/deja-vu"

✗ 400 {"error":"No values to set"}

The server row is created and the update that would fill it in fails. The result is a live but empty listing — no description, connections: [], tools: null — which does not show up in search:

{"qualifiedName":"vshulcz/deja-vu","displayName":"deja-vu","description":"",
 "remote":false,"deploymentUrl":null,"connections":[],"tools":null}

That is arguably worse than the first failure, which at least leaves nothing behind. Whatever the fix for the schema mismatch turns out to be, the two-step publish probably also wants to be atomic, or to fail before creating the row.

Happy to test a fix against a real bundle — mine is public and reproduces in one command.

[vshulcz]

One more data point, since it may narrow the fix: local stdio servers clearly can end up listed correctly. xue20010808/readfile_mcp is remote: false with a stdio connection, a bundleUrl in your storage, runtime: node — and a full tools array with inputSchema:

"connections":[{"type":"stdio","bundleUrl":"…/server.mcpb","runtime":"node","configSchema":{}}],
"tools":[{"name":"echo_hello","description":"…","inputSchema":{"type":"object",…}}]

So the registry stores exactly the shape the MCPB manifest cannot express. Whatever path produced that entry is the one mcp publish should be taking.

I tested the obvious hypothesis on my side — that the tools come from launching the bundle — by shipping an entry point that really starts the server (node server/index.js answers initialize and lists all four tools out of the unpacked bundle). Publishing it fails identically with No values to set, so the CLI does not appear to introspect; it sends manifest-derived values only.

The web form is not an alternative for this class of server either: it requires "a URL to a running server, not a GitHub repository", and a local-first tool that reads files on the user's own disk has no such URL by design.