SoraMCP is an MCP server for AI video generation using OpenAI's Sora model via the AceDataCloud API, compatible with clients like Claude, VS Code, and Cursor.
Video Generation
Text-to-Video (sora_generate_video / sora_generate_video_v2): Generate videos from text prompts, with options for model (sora-2 or sora-2-pro), size, orientation, and duration. V2 supports precise pixel-based resolutions (e.g., 1280×720) and shorter durations (4, 8, or 12 seconds).
Image-to-Video (sora_generate_video_from_image): Animate static images or generate videos aligned with a reference image's visual style.
Character Video (sora_generate_video_with_character): Reuse animated/digital characters from a reference video in new scenes (real people not supported).
Async Generation (sora_generate_video_async / sora_generate_video_v2_async): Submit generation tasks that notify a callback/webhook URL on completion, suitable for production workflows.
Task Management
Query Single Task (sora_get_task): Check status (pending, succeeded, failed) and retrieve video URLs for a specific task.
Batch Task Query (sora_get_tasks_batch): Check the status of multiple tasks at once (up to 50 recommended).
Discovery
List Models (sora_list_models): View available Sora models with capabilities, limits, and recommended use cases.
List Actions (sora_list_actions): Browse all available API actions and their corresponding tools.
Enables AI video generation using the Sora model, allowing users to create videos from text or images, maintain character consistency across scenes, and customize output orientations and durations.
Status: This MCP integration is retired and is no longer actively offered.
A Model Context Protocol (MCP) server for AI video generation using Sora through the AceDataCloud API.
Generate AI videos directly from Claude, VS Code, or any MCP-compatible client.
Text-to-Video - Generate videos from text descriptions
Image-to-Video - Animate images and create videos from reference images
Character Videos - Reuse characters across different scenes
Async Generation - Webhook callbacks for production workflows
Multiple Orientations - Landscape and portrait videos
Task Tracking - Monitor generation progress and retrieve results
Related MCP server: Sora2 MCP
Tool | Description |
| Generate an AI video from a text prompt using Sora. |
| Generate an AI video from reference images using Sora (Image-to-Video). |
| Generate an AI video featuring a character from a reference video. |
| Generate an AI video asynchronously with callback notification. |
| Generate an AI video using Sora Version 2 (partner channel). |
| Generate an AI video asynchronously using Sora Version 2 with callback. |
| Query the status and result of a video generation task. |
| Query multiple video generation tasks at once. |
| List all available Sora models and their capabilities. |
| List all available Sora API actions and corresponding tools. |
Sign in to AceDataCloud Platform
Open Applications and copy an existing API token
AceDataCloud hosts a managed MCP server — no local installation required.
Endpoint: https://sora.mcp.acedata.cloud/mcp
All requests require a Bearer token. Use the API token from Step 1.
Connect directly on Claude.ai with OAuth — no API token needed:
Go to Claude.ai Settings → Integrations → Add More
Enter the server URL: https://sora.mcp.acedata.cloud/mcp
Complete the OAuth login flow
Start using the tools in your conversation
Add to your config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP config (.cursor/mcp.json or .windsurf/mcp.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your VS Code MCP config (.vscode/mcp.json):
{
"servers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Or install the Ace Data Cloud MCP extension for VS Code, which registers the hosted MCP servers with one-click setup.
Go to Settings → Tools → AI Assistant → Model Context Protocol (MCP)
Click Add → HTTP
Paste:
{
"mcpServers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code supports MCP servers natively:
claude mcp add sora --transport http https://sora.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"Or add to your project's .mcp.json:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Cline's MCP settings (.cline/mcp_settings.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to your MCP configuration:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to Roo Code MCP settings:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Add to .continue/config.yaml:
mcpServers:
- name: sora
type: streamable-http
url: https://sora.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Add to Zed's settings (~/.config/zed/settings.json):
{
"language_models": {
"mcp_servers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
}# Health check (no auth required)
curl https://sora.mcp.acedata.cloud/health
# MCP initialize
curl -X POST https://sora.mcp.acedata.cloud/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'If you prefer to run the server on your own machine:
# Install from PyPI
pip install mcp-sora
# or
uvx mcp-sora
# Set your API token
export ACEDATACLOUD_API_TOKEN="your_token_here"
# Run (stdio mode for Claude Desktop / local clients)
mcp-sora
# Run (HTTP mode for remote access)
mcp-sora --transport http --port 8000{
"mcpServers": {
"sora": {
"command": "uvx",
"args": ["mcp-sora"],
"env": {
"ACEDATACLOUD_API_TOKEN": "your_token_here"
}
}
}
}docker pull ghcr.io/acedatacloud/mcp-sora:latest
docker run -p 8000:8000 ghcr.io/acedatacloud/mcp-sora:latestClients connect with their own Bearer token — the server extracts the token from each request's Authorization header.
Tool | Description |
| Generate video from a text prompt |
| Generate video from reference images |
| Generate video with a character from reference video |
| Generate video with callback notification |
Tool | Description |
| Query a single task status |
| Query multiple tasks at once |
Tool | Description |
| List available Sora models |
| List available API actions |
User: Create a video of a sunset over mountains
Claude: I'll generate a sunset video for you.
[Calls sora_generate_video with prompt="A beautiful sunset over mountains..."]User: Animate this image of a city skyline
Claude: I'll bring this image to life.
[Calls sora_generate_video_from_image with image_urls and prompt]User: Use the robot character in a new scene
Claude: I'll create a new scene with the robot character.
[Calls sora_generate_video_with_character with character_url and prompt]Model | Max Duration | Quality | Features |
| 15 seconds | Good | Standard generation |
| 25 seconds | Best | Higher quality, longer videos |
Size:
small - Lower resolution, faster generation
large - Higher resolution (recommended)
Orientation:
landscape - 16:9 (YouTube, presentations)
portrait - 9:16 (TikTok, Instagram Stories)
Duration:
10 seconds - All models
15 seconds - All models
25 seconds - sora-2-pro only
Variable | Description | Default |
| API token from AceDataCloud | Required |
| API base URL |
|
| OAuth client ID (hosted mode) | — |
| Platform base URL |
|
| Default model |
|
| Default video size |
|
| Default duration (seconds) |
|
| Default orientation |
|
| Request timeout (seconds) |
|
| Logging level |
|
mcp-sora --help
Options:
--version Show version
--transport Transport mode: stdio (default) or http
--port Port for HTTP transport (default: 8000)# Clone repository
git clone https://github.com/AceDataCloud/SoraMCP.git
cd SoraMCP
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # or `.venv\Scripts\activate` on Windows
# Install with dev dependencies
pip install -e ".[dev,test]"# Run unit tests
pytest
# Run with coverage
pytest --cov=core --cov=tools
# Run integration tests (requires API token)
pytest tests/test_integration.py -m integration# Format code
ruff format .
# Lint code
ruff check .
# Type check
mypy core tools# Install build dependencies
pip install -e ".[release]"
# Build package
python -m build
# Upload to PyPI
twine upload dist/*SoraMCP/
├── core/ # Core modules
│ ├── __init__.py
│ ├── client.py # HTTP client for Sora API
│ ├── config.py # Configuration management
│ ├── exceptions.py # Custom exceptions
│ ├── server.py # MCP server initialization
│ ├── types.py # Type definitions
│ └── utils.py # Utility functions
├── tools/ # MCP tool definitions
│ ├── __init__.py
│ ├── video_tools.py # Video generation tools
│ ├── task_tools.py # Task query tools
│ └── info_tools.py # Information tools
├── prompts/ # MCP prompt templates
│ └── __init__.py
├── tests/ # Test suite
│ ├── conftest.py
│ ├── test_client.py
│ ├── test_config.py
│ ├── test_integration.py
│ └── test_utils.py
├── deploy/ # Deployment configs
│ └── production/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ └── service.yaml
├── .env.example # Environment template
├── .gitignore
├── CHANGELOG.md
├── Dockerfile # Docker image for HTTP mode
├── docker-compose.yaml # Docker Compose config
├── LICENSE
├── main.py # Entry point
├── pyproject.toml # Project configuration
└── README.mdContributions are welcome! Please:
Fork the repository
Create a feature branch (git checkout -b feature/amazing)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing)
Open a Pull Request
MIT License - see LICENSE for details.
Made with love by AceDataCloud
Generate an AI video from a text prompt using Sora.
This is the primary way to create videos - describe what you want and Sora
will generate a video matching your description.
Use this when:
- You want to generate a video from a text description
- You don't have reference images
- You want creative AI-generated video content
For image-to-video generation, use sora_generate_video_from_image instead.
For character-based video generation, use sora_generate_video_with_character.
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' is the standard model. 'sora-2-pro' offers higher quality and supports 25-second videos. | sora-2 |
| prompt | Yes | Description of the video to generate. Be descriptive about the scene, action, style, and mood. Examples: 'A cat running on the river', 'A futuristic cityscape with flying cars at sunset', 'A person walking through a snowy forest' | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only available with sora-2-pro model). | |
| orientation | No | Video orientation. 'landscape' for horizontal (16:9), 'portrait' for vertical (9:16). | landscape |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool creates a video, which implies a non-read action, and mentions it returns task ID and video info. It could note that generation may take time, but the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loaded with the main action. It is slightly long but each section adds value. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, many siblings, output schema exists), the description covers purpose, usage guidelines, and parameter context thoroughly. The output schema handles return value details, so no gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level detail beyond the schema, but the schema already provides sufficient descriptions for all 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates an AI video from a text prompt using Sora, a specific verb+resource. It distinguishes from siblings like sora_generate_video_from_image and sora_generate_video_with_character by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use this tool (e.g., 'when you want to generate a video from a text description') and when not to, with direct references to alternative tools for image-to-video and character-based generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video asynchronously with callback notification.
This is useful for long-running video generation tasks. Instead of waiting
for the video to complete, you'll receive a callback at your specified URL
when the generation is finished.
Use this when:
- You don't want to wait for the generation to complete
- You have a webhook endpoint to receive results
- You're integrating with an async workflow
The callback will receive a POST request with the same response format
as the synchronous generation tools.
Returns:
Task ID that you can use to correlate with the callback.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. | large |
| model | No | Sora model version. | sora-2 |
| prompt | Yes | Description of the video to generate. | |
| duration | No | Video duration in seconds. | |
| image_urls | No | Optional list of reference image URLs for image-to-video generation. | |
| orientation | No | Video orientation. | landscape |
| callback_url | Yes | URL to receive the callback when video generation is complete. The result will be POSTed to this URL as JSON. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async behavior, callback POST with response format, and return of Task ID. Does not mention potential failures or retry behavior, but covers key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a lead sentence, a usage section with bullet points, and a return statement. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and existence of output schema, the description covers async behavior, callback, and task ID. It does not explicitly differentiate from siblings like sora_generate_video_v2_async, but is otherwise complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new semantics beyond what the schema provides. The callback_url parameter is explained in context of async, but this is minimal enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate an AI video asynchronously with callback notification.' It distinguishes itself from synchronous siblings like sora_generate_video by emphasizing the async nature and callback mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this when' bullet points (don't want to wait, have webhook, async workflow). It lacks explicit 'when not to use' or direct sibling comparisons, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video from reference images using Sora (Image-to-Video).
This allows you to animate or create videos based on provided images.
The AI will use the images as visual references for the generated video.
Use this when:
- You have reference images you want to animate
- You want the video to match a specific visual style
- You want to bring static images to life
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' or 'sora-2-pro' for higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate based on the image. Describe the action or motion you want to see. | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only for sora-2-pro). | |
| image_urls | Yes | List of reference image URLs to use for video generation. Can be image URLs or Base64 encoded images. | |
| orientation | No | Video orientation. 'landscape', 'portrait'. | landscape |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the return format (Task ID, URLs, state) but lacks info on rate limits, authentication, or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: first paragraph states core function, second paragraph explains usage, and last line summarizes return. Every sentence earns its place, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 required, 4 enums, and an output schema (mentioned in description), the description covers purpose, usage, and returns. Could add more detail on async behavior or limitations, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds high-level context but no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Generate an AI video from reference images using Sora (Image-to-Video)' and explains it animates images, distinguishing from siblings like sora_generate_video which likely doesn't use images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when:' list with three clear scenarios, but does not explicitly mention when not to use or alternatives. Still offers clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video using Sora Version 2 (partner channel).
Version 2 offers shorter video durations (4/8/12 seconds) with
precise pixel-based resolution control. This is ideal for quick
video generation with specific resolution requirements.
Use this when:
- You need precise pixel resolution control (e.g., 1280x720)
- You want shorter videos (4, 8, or 12 seconds)
- You want to use the partner channel for generation
For longer videos (10-25 seconds) or character-based generation,
use the version 1 tools (sora_generate_video, etc.) instead.
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution in pixels. Options: '720x1280' (vertical), '1280x720' (horizontal), '1024x1792' (tall vertical), '1792x1024' (wide horizontal). | 1280x720 |
| model | No | Sora model version. 'sora-2' is standard, 'sora-2-pro' offers higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate. Be descriptive about the scene, action, style, and mood. | |
| duration | No | Video duration in seconds. Options: 4, 8, or 12. | |
| image_urls | No | Optional list of reference image URLs. Only the first image is used for version 2. Image dimensions should match the size parameter. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return value (Task ID and video info) but lacks details on limitations, auth requirements, or potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise intro, bullet-pointed use cases, alternative suggestion, and return statement. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, usage, and return value. Lacks explicit mention of async behavior (though async sibling exists) and could clarify that generation might be asynchronous. Output schema helps but description leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, and description adds extra context (e.g., only first image used for v2, resolution options). Provides meaningful interpretation beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates AI videos using Sora Version 2 with specific characteristics (shorter durations, pixel resolution control). Distinguishes from sibling tools by mentioning version 1 for longer/character videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (precise resolution, shorter videos, partner channel) and when not to use (longer videos, character generation) with direct references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video asynchronously using Sora Version 2 with callback.
Similar to sora_generate_video_v2 but returns immediately with a task ID.
The result will be POSTed to your callback URL when generation completes.
Use this when:
- You don't want to wait for the generation to complete
- You have a webhook endpoint to receive results
- You're integrating with an async workflow
Returns:
Task ID that you can use to correlate with the callback.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution in pixels. | 1280x720 |
| model | No | Sora model version. | sora-2 |
| prompt | Yes | Description of the video to generate. | |
| duration | No | Video duration in seconds. Options: 4, 8, or 12. | |
| image_urls | No | Optional list of reference image URLs. Only the first image is used. | |
| callback_url | Yes | URL to receive the callback when video generation is complete. The result will be POSTed to this URL as JSON. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly explains the async behavior, immediate return of task ID, and the callback mechanism. However, it does not disclose potential side effects or limitations like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a comparison to the sync version, a list of use cases, and the return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters, full schema coverage, and the presence of an output schema (mentioned in context), the description adequately covers the tool's functionality and return value. Missing details about error handling or rate limits, but still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only emphasizing the async nature and callback usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates an AI video asynchronously using Sora Version 2 with a callback, distinguishing it from the synchronous sibling sora_generate_video_v2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases: when you don't want to wait, have a webhook endpoint, or are integrating with an async workflow. This provides clear guidance on when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI video featuring a character from a reference video.
This allows you to create new videos featuring a specific character
extracted from another video. The character will be placed in the
new scene described by the prompt.
IMPORTANT: The reference video must NOT contain real people.
Only animated or digital characters are supported.
Use this when:
- You want to reuse a character in different scenes
- You're creating a series with the same character
- You want consistent character appearance across videos
Returns:
Task ID and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Video resolution. 'small' for lower resolution, 'large' for higher resolution. | large |
| model | No | Sora model version. 'sora-2' or 'sora-2-pro' for higher quality. | sora-2 |
| prompt | Yes | Description of the video to generate featuring the character. Describe the scene and action. | |
| duration | No | Video duration in seconds. Options: 10, 15, or 25 (25 only for sora-2-pro). | |
| orientation | No | Video orientation. 'landscape', 'portrait'. | landscape |
| character_end | No | End position of the character in the reference video (0-1 range). For example, 0.8 means the character ends at 80% of the video. | |
| character_url | Yes | URL of the video containing the character to use. IMPORTANT: The video must NOT contain real people, only animated/digital characters. | |
| character_start | No | Start position of the character in the reference video (0-1 range). For example, 0.2 means the character appears at 20% from the start. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return includes Task ID and video info, and the limitation about real people. But it doesn't detail behavior like character selection from multi-character videos or potential mutation of the reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with key purpose, followed by an important constraint and usage guidance. It is efficient but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema coverage, the description covers essential context. However, it lacks guidance on parameter choices (model, size, orientation) and does not fully address potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no new parameter semantics beyond the schema; it only weakly contextualizes prompt and character_url.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates AI videos featuring a character from a reference video, distinguishing it from sibling tools like sora_generate_video. It specifies the resource (video with character) and strongly implies the extraction process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this when' bullet points provide clear scenarios (reusing characters, creating series, consistent appearance). However, it lacks explicit mention of when NOT to use it versus alternatives like sora_generate_video.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of a video generation task.
Use this to check if a generation is complete and retrieve the resulting
video URLs and metadata.
Use this when:
- You want to check if a generation has completed
- You need to retrieve video URLs from a previous generation
- You want to get the full details of a generated video
Task states:
- 'pending': Generation is still in progress
- 'succeeded': Generation finished successfully
- 'failed': Generation failed (check error message)
Returns:
Task status and generated video information including URLs and state.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from a video generation request. This is the 'task_id' field from any sora_generate_* tool response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses task states (pending, succeeded, failed) and return of URLs/metadata. Could mention idempotency or rate limits, but sufficient for polling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for use cases and states. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description explains use cases and states, fully adequate for a simple polling tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Description adds no extra meaning beyond schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query the status and result of a video generation task' with specific verb and resource. It lists distinct use cases, differentiating it from sibling generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' list with three scenarios. While no explicit when-not or alternatives, the use cases imply context. Slight lack of exclusion guidance keeps from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query multiple video generation tasks at once.
Efficiently check the status of multiple tasks in a single request.
More efficient than calling sora_get_task multiple times.
Use this when:
- You have multiple pending generations to check
- You want to get status of several videos at once
- You're tracking a batch of generations
Returns:
Status and video information for all queried tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | List of task IDs to query. Maximum recommended batch size is 50 tasks. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions efficiency and returns but lacks details on rate limits, auth, or errors. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bulleted usage list. Could be more concise but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so description doesn't need to detail returns. With one parameter and clear operation, it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with good description including max batch size. Description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries multiple video generation tasks efficiently, distinguishing it from sibling sora_get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: multiple pending generations, status of several videos, tracking batch. Implies single-task use should go to sora_get_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sora API actions and corresponding tools.
Reference guide for what each action does and which tool to use.
Helpful for understanding the full capabilities of the Sora MCP.
Returns:
Categorized list of all actions and their corresponding tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return is a 'Categorized list of all actions and their corresponding tools,' which is transparent. However, it does not mention any behavioral traits like idempotency, rate limits, or authentication requirements. For a simple read-only tool, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no extraneous information. The first sentence front-loads the primary purpose. Every sentence serves a purpose: stating action, explaining utility, and describing output. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description fully covers what an agent needs to know: it lists actions and tools, serves as a reference, and returns categorized output. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description adds value by detailing the return structure ('Categorized list'), which is beyond what the schema provides. No parameter explanation is needed, so the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available Sora API actions and corresponding tools.' The verb 'list' combined with the resource 'actions and tools' makes the function unambiguous. It distinguishes itself from sibling tools like sora_generate_video by being a meta-discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used as a 'Reference guide' to understand capabilities before using other tools. While it doesn't explicitly state when not to use it, the context makes it clear that it's for exploration, not execution. No alternative tools are mentioned, but the distinction from siblings is inherent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sora models and their capabilities.
Shows all available model versions with their limits, features, and
recommended use cases. Use this to understand which model to choose
for your video generation.
Returns:
Table of all models with their version, limits, and features.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool 'shows all available model versions with their limits, features, and recommended use cases,' accurately describing the read-only behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the purpose. Every sentence adds meaningful information with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema exists (so return values are documented), the description is complete. It explains the tool's purpose and what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), so schema coverage is 100% by default. The description adds value by stating what information is shown (limits, features, use cases), which is beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available Sora models and their capabilities,' specifying the resource (models) and action (list). It is distinct from sibling tools like sora_generate_video and sora_get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it 'to understand which model to choose for your video generation,' providing clear context. It doesn't explicitly mention when not to use it, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.4sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsv0.1.2sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsv0.1.0sora_generate_videosora_generate_video_asyncsora_generate_video_from_imagesora_generate_video_v2sora_generate_video_v2_asyncsora_generate_video_with_charactersora_get_tasksora_get_tasks_batchsora_list_actionssora_list_modelsEach generation tool targets a distinct input method (text, image, character, v2) and synchronous/asynchronous modes are clearly separated. Descriptions explicitly note differences, so an agent can easily select the appropriate tool.
All tools follow a consistent sora_verb_noun pattern in snake_case (e.g., sora_generate_video, sora_get_task). The version suffixes (_v2) are appended uniformly, maintaining predictability.
With 10 tools, the set is well-scoped for a video generation service. It covers generation variants, status checks, and listing actions/models without being bloated or too sparse.
The tool surface covers generation, status retrieval (single and batch), and informational queries. A minor gap is the lack of a cancellation tool for pending tasks, but it's not critical for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OpenAI Sora: Sora & Sora 2 (new social media like TikTok) API by ChatGPT creator OpenAI. Access.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
Generate finished AI videos from a brief or a script, with voiceover, scenes and captions.
Image, video, music and text generation across 100+ models through one endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/SoraMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
