Summary
Claude Desktop's extension runtime appears to validate the content a bundled extension serves via prompts/get against the prompts[].text declared in manifest.json, rejecting the prompt on mismatch. This is a sensible defense (a server could otherwise swap prompt content after install/review), but it doesn't seem to be documented in MANIFEST.md, and the error gives the author no hint that the manifest is involved:
Extension prompt "" content validation failed. Rejecting response to prevent potential prompt injection.
followed by "Failed to attach prompt. You can try again."
How we isolated it
Our manifest carried a one-line summary in prompts[].text while the server serves the full ~2.7 KB prompt text (we'd read the field as listing metadata, like tools[].description):
- Summary text in manifest + original served wording → rejected
- Summary text in manifest + fully rewritten served wording (all injection-pattern phrasing removed) → still rejected — so it isn't (only) a content classifier
- Manifest
text byte-identical to the served text → accepted, prompt attaches and runs
Tools are unaffected by mismatched tools[].description (they remained callable throughout), which reinforced the misreading of prompts[].text as display metadata.
Suggestions (any subset helps)
- Document in MANIFEST.md that for prompts,
text is (or is treated by Claude Desktop as) the canonical content the server must serve, not a summary — and what the comparison is (exact match? normalized?)
- Have
mcpb validate or mcpb pack warn when a bundle's declared prompt text looks like a summary (e.g., much shorter than typical prompt content) — or better, offer a check that runs the bundled server and diffs prompts/get against the manifest
- Surface a more actionable client error, e.g. "served prompt content does not match the manifest declaration"
Happy to provide the bundle or a minimal reproduction. Our fix, for reference (generate prompts[].text from the same module the server registers from, with a byte-equality check in the build): elicitly/elicitly#32
Summary
Claude Desktop's extension runtime appears to validate the content a bundled extension serves via
prompts/getagainst theprompts[].textdeclared inmanifest.json, rejecting the prompt on mismatch. This is a sensible defense (a server could otherwise swap prompt content after install/review), but it doesn't seem to be documented in MANIFEST.md, and the error gives the author no hint that the manifest is involved:followed by "Failed to attach prompt. You can try again."
How we isolated it
Our manifest carried a one-line summary in
prompts[].textwhile the server serves the full ~2.7 KB prompt text (we'd read the field as listing metadata, liketools[].description):textbyte-identical to the served text → accepted, prompt attaches and runsTools are unaffected by mismatched
tools[].description(they remained callable throughout), which reinforced the misreading ofprompts[].textas display metadata.Suggestions (any subset helps)
textis (or is treated by Claude Desktop as) the canonical content the server must serve, not a summary — and what the comparison is (exact match? normalized?)mcpb validateormcpb packwarn when a bundle's declared prompt text looks like a summary (e.g., much shorter than typical prompt content) — or better, offer a check that runs the bundled server and diffsprompts/getagainst the manifestHappy to provide the bundle or a minimal reproduction. Our fix, for reference (generate
prompts[].textfrom the same module the server registers from, with a byte-equality check in the build): elicitly/elicitly#32