AceDataCloud APIを通じてSoraを利用したAI動画生成を行うModel Context Protocol (MCP)サーバーです。
Claude、VS Code、またはMCP互換クライアントから直接AI動画を生成できます。
テキストから動画 (Text-to-Video) - テキストの説明から動画を生成
画像から動画 (Image-to-Video) - 画像をアニメーション化し、参照画像から動画を作成
キャラクター動画 - 異なるシーン間でキャラクターを再利用
非同期生成 - 本番ワークフロー向けのWebhookコールバック
複数の向き - 横長および縦長の動画
タスク追跡 - 生成の進捗状況を監視し、結果を取得
Related MCP server: Sora2 MCP
ツール | 説明 |
| Soraを使用してテキストプロンプトからAI動画を生成します。 |
| Soraを使用して参照画像からAI動画を生成します（画像から動画）。 |
| 参照動画のキャラクターを使用してAI動画を生成します。 |
| コールバック通知付きで非同期にAI動画を生成します。 |
| Soraバージョン2（パートナーチャネル）を使用してAI動画を生成します。 |
| コールバック付きでSoraバージョン2を使用して非同期にAI動画を生成します。 |
| 動画生成タスクのステータスと結果を照会します。 |
| 複数の動画生成タスクを一度に照会します。 |
| 利用可能なすべてのSoraモデルとその機能を一覧表示します。 |
| 利用可能なすべてのSora APIアクションと対応するツールを一覧表示します。 |
AceDataCloud Platformにサインアップ
APIドキュメントページに移動
**「Acquire」**をクリックしてAPIトークンを取得
トークンをコピーして以下で使用
AceDataCloudが管理するMCPサーバーをホストしているため、ローカルインストールは不要です。
エンドポイント: https://sora.mcp.acedata.cloud/mcp
すべてのリクエストにはBearerトークンが必要です。ステップ1で取得したAPIトークンを使用してください。
Claude.aiでOAuthを使用して直接接続します（APIトークンは不要です）：
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トークンで接続します。サーバーは各リクエストのAuthorizationヘッダーからトークンを抽出します。
ツール | 説明 |
| テキストプロンプトから動画を生成 |
| 参照画像から動画を生成 |
| 参照動画のキャラクターを使用して動画を生成 |
| コールバック通知付きで動画を生成 |
ツール | 説明 |
| 単一のタスクステータスを照会 |
| 複数のタスクを一度に照会 |
ツール | 説明 |
| 利用可能な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ストーリー）
時間:
10秒 - 全モデル
15秒 - 全モデル
25秒 - sora-2-proのみ
変数 | 説明 | デフォルト |
| AceDataCloudのAPIトークン | 必須 |
| 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 - タスク照会
貢献を歓迎します！以下の手順に従ってください：
リポジトリをフォーク
フィーチャーブランチを作成 (git checkout -b feature/amazing)
変更をコミット (git commit -m 'Add amazing feature')
ブランチにプッシュ (git push origin feature/amazing)
プルリクエストを作成
MITライセンス - 詳細はLICENSEを参照してください。
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.
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.
