OpenAI SDK Architecture
This guide explains how MCPJam Inspector implements the OpenAI Apps SDK to render custom UI components for MCP tool results. This enables MCP server developers to create rich, interactive visualizations for their tool outputs.Overview
MCPJam Inspector provides full support for the OpenAI Apps SDK, allowing MCP tools to return custom UI components that render in iframes with a sandboxedwindow.openai
API bridge.
Key Features
- Custom UI Rendering: Display tool results using custom HTML/React components
- Interactive Widgets: Components can call other MCP tools and send followup messages
- State Persistence: Widget state persists across sessions via localStorage
- Secure Isolation: Components run in sandboxed iframes with CSP headers
- Dual Mode Support:
ui://
URIs for server-provided HTML content- External URLs for remotely hosted components
Architecture Overview
Component Flow
1. Tool Execution & Detection
When a tool is executed that returns OpenAI SDK components, the system detects this in two ways: Method A:_meta["openai/outputTemplate"]
field
ui://
resource in response
ResultsPanel Detection Logic
Located inclient/src/components/tools/ResultsPanel.tsx:100-104
:
resolveUIResource
function searches for ui://
URIs in:
- Direct
resource
field at root level content
array items withtype: "resource"
2. Widget Data Storage Flow
Before rendering, widget data must be stored server-side for iframe access: Why Store Server-Side?- Iframes need access to
toolInput
andtoolOutput
forwindow.openai
API - Client localStorage can’t be shared across iframe sandbox boundaries
- Server becomes the source of truth for widget initialization data
Storage Implementation
Located inserver/routes/mcp/resources.ts:6-30
:
3. Two-Stage Widget Loading
The system uses a clever two-stage loading process to ensure React Router compatibility: Why Two Stages?- Many widgets use React Router’s
BrowserRouter
which expects clean URLs - Stage 1 changes URL to ”/” before widget code loads
- Stage 2 fetches actual content after URL is reset
- Prevents routing conflicts and 404 errors
Stage 1: Container Page
Located inserver/routes/mcp/resources.ts:131-170
:
Stage 2: Content Injection
Located inserver/routes/mcp/resources.ts:173-438
:
Key steps:
- Retrieve widget data from store
- Read HTML from MCP server via
readResource(uri)
- Inject
window.openai
API script - Add security headers (CSP, X-Frame-Options)
- Set cache control headers (no-cache for fresh content)
4. window.openai API Bridge
The injected script provides the OpenAI Apps SDK API to widget code:API Implementation
Located inserver/routes/mcp/resources.ts:250-376
:
Core API Methods:
- API is frozen with
writable: false, configurable: false
- 30-second timeout on tool calls prevents hanging requests
- Origin validation in parent ensures only iframe messages are processed
5. Parent-Side Message Handling
Located inclient/src/components/chat/openai-component-renderer.tsx:118-196
:
Tool Execution Bridge
Located inclient/src/components/ChatTab.tsx:181-207
:
Security Architecture
Content Security Policy
Located inserver/routes/mcp/resources.ts:408-422
:
Iframe Sandbox
Located inclient/src/components/chat/openai-component-renderer.tsx:218-230
:
allow-scripts
: Enable JavaScript executionallow-same-origin
: Allow localStorage access (required for state)allow-forms
: Support form submissionsallow-popups
: Enable external link navigationallow-popups-to-escape-sandbox
: Allow popup windows to load normally
allow-same-origin
+allow-scripts
= Full JavaScript capabilities- Required for React Router and modern frameworks
- Mitigated by CSP headers and origin validation
- Widgets should be treated as semi-trusted code
Complete Data Flow Example
Let’s trace a complete interaction where a widget calls a tool:Development Guide
Testing OpenAI SDK Widgets Locally
- Create a test MCP server with OpenAI SDK support:
- Add server to MCPJam Inspector config:
- Test in Inspector:
- Connect to server in Servers tab
- Navigate to Chat tab
- Execute: “Call the hello_widget tool with name John”
- Widget should render with interactive buttons
Debugging Widget Issues
Common Problems:-
Widget doesn’t load (404)
- Check that
widgetDataStore
contains toolId - Verify storage TTL hasn’t expired (1 hour default)
- Confirm MCP server returns valid HTML for
ui://
resource
- Check that
-
window.openai
is undefined- Verify script injection in Stage 2 content endpoint
- Check browser console for CSP violations
- Ensure
<head>
tag exists in HTML for injection
-
Tool calls timeout
- Check network tab for
/api/mcp/tools/execute
failures - Verify MCP server is connected and responsive
- Increase timeout in
callTool
implementation (default: 30s)
- Check network tab for
-
React Router 404 errors
- Confirm Stage 1 executes
history.replaceState('/')
before loading - Check that widget uses
BrowserRouter
notHashRouter
- Verify
<base href=\"/\">
is present in HTML
- Confirm Stage 1 executes
-
State doesn’t persist
- Check localStorage in browser DevTools
- Verify
widgetStateKey
format is consistent - Confirm
setWidgetState
postMessage handler is working
Extending the Implementation
Adding New OpenAI API Methods:- Update server-side injection script (
server/routes/mcp/resources.ts:250-376
) - Add postMessage handler in parent (
client/src/components/chat/openai-component-renderer.tsx:118-196
) - Update TypeScript types if needed
openExternal
method:
Performance Considerations
Widget Data Storage
- TTL: 1 hour default, configurable in
resources.ts:22
- Cleanup: Runs every 5 minutes
- Memory: Each widget stores ~1-10KB (toolInput + toolOutput)
- Scale: 1000 concurrent widgets ≈ 10MB memory
- Recommendation: For production, use Redis instead of Map
Iframe Rendering
- Initial Load: 200-500ms (Stage 1 + Stage 2 + resource fetch)
- Tool Calls: 100-300ms (postMessage + backend + MCP)
- Optimization:
- Cache MCP resource reads (currently disabled with
no-cache
) - Preload widget data before iframe creation
- Use service workers for offline support
- Cache MCP resource reads (currently disabled with
postMessage Overhead
- Latency: 5-15ms per message round-trip
- Payload: JSON serialization for all data
- Bottleneck: Large tool results (>1MB) slow down significantly
- Mitigation: Use streaming or chunked responses for large data
Security Best Practices
-
Validate postMessage Origins:
-
Sanitize Tool Parameters:
-
Limit Widget Capabilities:
- Only expose necessary MCP tools to widgets
- Implement rate limiting on tool calls
- Restrict network access via CSP
-
Content Security Policy:
- Remove
unsafe-eval
if possible (breaks some frameworks) - Whitelist only trusted CDNs
- Consider using nonces for inline scripts
- Remove
-
Audit Widget Code:
- Widgets have semi-trusted status
- Review HTML content from MCP servers
- Scan for XSS vulnerabilities
- Monitor for suspicious postMessage patterns
Related Files
client/src/components/tools/ResultsPanel.tsx
- Detects OpenAI componentsclient/src/components/chat/openai-component-renderer.tsx
- Renders iframesclient/src/components/ChatTab.tsx
- Chat integrationserver/routes/mcp/resources.ts
- Widget storage and servingclient/src/lib/mcp-tools-api.ts
- Tool execution API
Resources
- OpenAI Apps SDK - Custom UX Guide
- OpenAI Apps SDK - API Reference
- MCP Specification
- MCPJam Inspector Repository
Contributing
When contributing to the OpenAI SDK integration:- Test with real MCP servers - Don’t just mock the API
- Check security implications - All changes to iframe/postMessage code need review
- Update this documentation - Keep architecture diagrams current
- Add debug logging - Use
console.log
with[OpenAI Widget]
prefix - Consider backwards compatibility - Existing widgets should continue working