sanzaru
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUDIO_PATH | No | Path for audio storage | |
| IMAGE_PATH | No | Path for image storage | |
| VIDEO_PATH | No | Path for video storage | |
| OPENAI_API_KEY | Yes | Your OpenAI API key | |
| STORAGE_BACKEND | No | Storage backend (optional, e.g., 'databricks') | |
| SANZARU_MEDIA_PATH | No | Unified media path (auto-creates videos/, images/, audio/ subdirs) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_videoA | Create a new Sora video generation job. This starts an async job and returns immediately with a video_id. The video is NOT ready immediately - use get_video_status(video_id) to poll for completion. Status will be 'queued' -> 'in_progress' -> 'completed' or 'failed'. Once status='completed', use download_video(video_id) to save the video to disk. Parameters:
Returns Video object with fields: id, status, progress, model, seconds, size. |
| get_video_statusA | Check the status and progress of a video generation job. Use this to poll for completion after calling create_video or remix_video. Call this repeatedly (e.g. every 5-10 seconds) until status changes from 'queued'/'in_progress' to 'completed' or 'failed'. The returned Video object contains:
Typical workflow:
|
| download_videoA | Download a completed video to disk. IMPORTANT: Only call this AFTER get_video_status shows status='completed'. If the video is not completed, this will fail. The video is automatically saved to the directory configured in VIDEO_PATH. Returns the filename of the downloaded file. Parameters:
Typical workflow:
Returns DownloadResult with: filename, variant |
| list_videosA | List all video jobs in your OpenAI account with pagination support. Returns a paginated list of all videos (completed, in-progress, failed, etc.). Each video summary includes: id, status, progress, created_at, model, seconds, size. Parameters:
Returns:
Pagination example:
|
| delete_videoA | Permanently delete a video from OpenAI's cloud storage. WARNING: This is permanent and cannot be undone! The video will be deleted from OpenAI's servers. This does NOT delete any local files you may have downloaded with download_video. Use this to:
Parameters:
Returns confirmation with the deleted video_id and deleted=true. |
| remix_videoA | Create a NEW video by remixing an existing completed video with a different prompt. This creates a brand new video generation job (with a new video_id) based on an existing video. The original video must have status='completed' for remix to work. Like create_video, this returns immediately with a new video_id - the remix is NOT instant. You must poll the NEW video_id with get_video_status until it completes. Parameters:
Returns a NEW Video object with a different video_id, status='queued', progress=0. Typical workflow:
|
| list_local_videosA | List locally downloaded video files with filtering and sorting. Use this to discover what video files have been downloaded to the VIDEO_PATH directory. These are videos previously downloaded with download_video. Parameters:
Returns list of VideoFile objects with: filename, size_bytes, modified_timestamp, file_type. Example workflow:
|
| view_mediaA | Open a media file in the interactive media viewer. Opens a rich media player UI for viewing videos, listening to audio, or displaying images. The viewer loads the file and renders it with native playback controls. Parameters:
Use list_videos, list_reference_images, or list_audio_files to discover available files. Returns metadata: filename, media_type, size_bytes, mime_type |
| _get_media_dataA | Internal tool used by the MCP App media viewer to fetch base64-encoded chunks of media data. Do not call directly — use view_media instead. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| media_viewer_html | Serve the bundled media viewer MCP App HTML. |
TDQS
Scored across 9 tools
Each tool has a clearly distinct purpose: create/remix/status/download/delete/list remote/list local/view. The internal _get_media_data tool is explicitly marked as 'do not call directly,' and its relationship to view_media is clearly explained, eliminating potential confusion.
Tool names follow a consistent verb_noun pattern (create_video, delete_video, download_video, list_videos, view_media). Minor deviations include get_video_status (three-part), list_local_videos (adjective), and the underscore-prefixed _get_media_data, but these are readable and the pattern is predictable overall.
With 9 tools, the server is well-scoped for video generation and management. Each tool addresses a distinct step in the workflow (create, remix, status, download, delete, list remote/local, view), and the count feels appropriate without redundancy or bloat.
Core video lifecycle is covered (create, remix, status, download, delete, list). However, create_video and view_media reference list_reference_images and list_audio_files, but these tools are not provided, creating dead ends for workflows involving reference images or audio media. This is a notable gap in the tool surface.