modelcontextprotocol / modelcontextprotocol/ext-apps
Support `wasm-unsafe-eval` CSP directive to enable WebAssembly in MCP Apps
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 387
- Avg merge
- 3h 21m
- Merged PRs (30d)
- 6
Description
Problem
WebAssembly-based frameworks (Blazor, Uno Platform, Rust/Wasm, Go/Wasm, Pyodide, etc.) cannot run inside MCP App iframes because the current CSP does not include wasm-unsafe-eval in script-src.
When a Wasm module calls WebAssembly.compileStreaming() or WebAssembly.instantiate(), the browser blocks it:
Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an
allowed source of script in the following Content Security Policy directive: "script-src ..."
Why wasm-unsafe-eval and not unsafe-eval
The wasm-unsafe-eval directive was introduced specifically to decouple WebAssembly compilation from JavaScript eval(). It:
- Allows
WebAssembly.compile(),WebAssembly.instantiate(), andWebAssembly.compileStreaming() - Does not allow
eval(),new Function(), or other dynamic JS code generation - Is supported in all major browsers (Chrome 97+, Firefox 102+, Safari 16+)
- Is the recommended approach for enabling Wasm under CSP
This is significantly safer than unsafe-eval and addresses a different set of use cases.
Affected frameworks
Any framework that compiles to WebAssembly is blocked:
| Framework | Language | Use case |
|---|---|---|
| Blazor WebAssembly | C#/.NET | Full-stack .NET web apps |
| Uno Platform (Wasm) | C#/.NET | Cross-platform XAML apps |
| Pyodide | Python | Data science, notebooks |
| Rust/wasm-bindgen | Rust | Performance-critical components |
| Go (GOOS=js) | Go | Portable Go applications |
| AssemblyScript | TypeScript-like | Wasm-first development |
Proposal
Add a wasmUnsafeEval boolean (or a scriptPolicies array) to the CSP metadata that servers can declare:
{
"_meta": {
"ui": {
"csp": {
"resourceDomains": ["http://localhost:5173/"],
"connectDomains": ["http://localhost:5173/"],
"wasmUnsafeEval": true
}
}
}
}
Hosts that support it would add 'wasm-unsafe-eval' to the script-src directive of the iframe's CSP. Hosts that don't support it can safely ignore the field (Wasm simply won't load, which is the current behavior).
Related issues
- #199 —
unsafe-evalneeded for three.js (broader, includes JS eval) - #513 — Pyodide/Wasm performance in Claude.ai (related but focused on COOP/COEP headers)
- #58 — Sandbox capabilities negotiation (meta-issue)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the _meta.ui.csp metadata path and the iframe CSP script-src generation; inspect how resourceDomains and connectDomains are declared and applied. Done when a host can declare the Wasm opt-in, supported hosts emit 'wasm-unsafe-eval', unsupported hosts ignore it, and the behavior is covered by the repository's existing checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, wasm
- Domain
- api, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100