一个用于 AI 视频生成的 Model Context Protocol (MCP) 服务器，通过 AceDataCloud API 使用 Sora。
直接从 Claude、VS Code 或任何兼容 MCP 的客户端生成 AI 视频。
文生视频 (Text-to-Video) - 根据文本描述生成视频
图生视频 (Image-to-Video) - 动画化图像并根据参考图创建视频
角色视频 (Character Videos) - 在不同场景中复用角色
异步生成 (Async Generation) - 用于生产工作流的 Webhook 回调
多种方向 (Multiple Orientations) - 横屏和竖屏视频
任务追踪 (Task Tracking) - 监控生成进度并获取结果
Related MCP server: Sora2 MCP
工具 | 描述 |
| 使用 Sora 根据文本提示生成 AI 视频。 |
| 使用 Sora 根据参考图像生成 AI 视频（图生视频）。 |
| 生成包含参考视频中角色的 AI 视频。 |
| 异步生成 AI 视频并接收回调通知。 |
| 使用 Sora 第二版（合作伙伴通道）生成 AI 视频。 |
| 使用 Sora 第二版异步生成 AI 视频并接收回调。 |
| 查询视频生成任务的状态和结果。 |
| 同时查询多个视频生成任务。 |
| 列出所有可用的 Sora 模型及其功能。 |
| 列出所有可用的 Sora API 操作及对应工具。 |
在 AceDataCloud 平台 注册
前往 API 文档页面
点击 “Acquire” 获取您的 API token
复制该 token 以供下方使用
AceDataCloud 托管了一个受管理的 MCP 服务器 —— 无需本地安装。
端点： https://sora.mcp.acedata.cloud/mcp
所有请求都需要 Bearer token。请使用第 1 步中的 API token。
通过 OAuth 直接在 Claude.ai 上连接 —— 无需 API token：
前往 Claude.ai 设置 → 集成 → 添加更多
输入服务器 URL：https://sora.mcp.acedata.cloud/mcp
完成 OAuth 登录流程
开始在对话中使用这些工具
添加到您的配置中（macOS 上为 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到您的 MCP 配置（.cursor/mcp.json 或 .windsurf/mcp.json）：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到您的 VS Code MCP 配置（.vscode/mcp.json）：
{
"servers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}或者为 VS Code 安装 Ace Data Cloud MCP 扩展，该扩展集成了所有 15 个 MCP 服务器，支持一键设置。
前往 设置 → 工具 → AI Assistant → Model Context Protocol (MCP)
点击 添加 → HTTP
粘贴：
{
"mcpServers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code 原生支持 MCP 服务器：
claude mcp add sora --transport http https://sora.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"或者添加到项目的 .mcp.json 中：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到 Cline 的 MCP 设置（.cline/mcp_settings.json）：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到您的 MCP 配置：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到 Roo Code 的 MCP 设置：
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}添加到 .continue/config.yaml：
mcpServers:
- name: sora
type: streamable-http
url: https://sora.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"添加到 Zed 的设置（~/.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"}}}'如果您更喜欢在自己的机器上运行服务器：
# 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:latest客户端使用各自的 Bearer token 进行连接 —— 服务器会从每个请求的 Authorization 标头中提取 token。
工具 | 描述 |
| 根据文本提示生成视频 |
| 根据参考图像生成视频 |
| 生成包含参考视频中角色的视频 |
| 生成带有回调通知的视频 |
工具 | 描述 |
| 查询单个任务状态 |
| 同时查询多个任务 |
工具 | 描述 |
| 列出可用的 Sora 模型 |
| 列出可用的 API 操作 |
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]模型 | 最大时长 | 质量 | 功能 |
| 15 秒 | 良好 | 标准生成 |
| 25 秒 | 最佳 | 更高质量，更长视频 |
尺寸：
small - 低分辨率，生成速度更快
large - 高分辨率（推荐）
方向：
landscape - 16:9（YouTube，演示文稿）
portrait - 9:16（TikTok，Instagram Stories）
时长：
10 秒 - 所有模型
15 秒 - 所有模型
25 秒 - 仅限 sora-2-pro
变量 | 描述 | 默认值 |
| AceDataCloud 的 API token | 必需 |
| API 基础 URL |
|
| OAuth 客户端 ID（托管模式） | — |
| 平台基础 URL |
|
| 默认模型 |
|
| 默认视频尺寸 |
|
| 默认时长（秒） |
|
| 默认方向 |
|
| 请求超时（秒） |
|
| 日志级别 |
|
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.md此服务器封装了 AceDataCloud Sora API：
Sora Videos API - 视频生成
Sora Tasks API - 任务查询
欢迎贡献！请：
Fork 本仓库
创建功能分支 (git checkout -b feature/amazing)
提交更改 (git commit -m 'Add amazing feature')
推送到分支 (git push origin feature/amazing)
开启 Pull Request
MIT 许可证 - 详情请参阅 LICENSE。
由 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.
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_modelsScored across 10 tools
Each 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.
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.
Image, video, music and text generation across 100+ models through one endpoint.
One API for 100+ AI video, image, music and speech models.
