Ein Model Context Protocol (MCP)-Server für KI-Videogenerierung mit Sora über die AceDataCloud API.
Generieren Sie KI-Videos direkt aus Claude, VS Code oder einem beliebigen MCP-kompatiblen Client.
Text-zu-Video - Generieren Sie Videos aus Textbeschreibungen
Bild-zu-Video - Animieren Sie Bilder und erstellen Sie Videos aus Referenzbildern
Charakter-Videos - Wiederverwendung von Charakteren in verschiedenen Szenen
Asynchrone Generierung - Webhook-Callbacks für Produktions-Workflows
Mehrere Ausrichtungen - Videos im Quer- und Hochformat
Aufgabenverfolgung - Überwachen Sie den Generierungsfortschritt und rufen Sie Ergebnisse ab
Related MCP server: Sora2 MCP
Tool | Beschreibung |
| Generiert ein KI-Video aus einem Text-Prompt mit Sora. |
| Generiert ein KI-Video aus Referenzbildern mit Sora (Bild-zu-Video). |
| Generiert ein KI-Video mit einem Charakter aus einem Referenzvideo. |
| Generiert ein KI-Video asynchron mit Callback-Benachrichtigung. |
| Generiert ein KI-Video mit Sora Version 2 (Partnerkanal). |
| Generiert ein KI-Video asynchron mit Sora Version 2 und Callback. |
| Fragt den Status und das Ergebnis einer Videogenerierungsaufgabe ab. |
| Fragt mehrere Videogenerierungsaufgaben gleichzeitig ab. |
| Listet alle verfügbaren Sora-Modelle und deren Funktionen auf. |
| Listet alle verfügbaren Sora-API-Aktionen und die entsprechenden Tools auf. |
Registrieren Sie sich auf der AceDataCloud-Plattform
Gehen Sie zur API-Dokumentationsseite
Klicken Sie auf "Acquire", um Ihr API-Token zu erhalten
Kopieren Sie das Token für die untenstehende Verwendung
AceDataCloud hostet einen verwalteten MCP-Server — keine lokale Installation erforderlich.
Endpunkt: https://sora.mcp.acedata.cloud/mcp
Alle Anfragen erfordern ein Bearer-Token. Verwenden Sie das API-Token aus Schritt 1.
Verbinden Sie sich direkt auf Claude.ai mit OAuth — kein API-Token erforderlich:
Gehen Sie zu Claude.ai Einstellungen → Integrationen → Mehr hinzufügen
Geben Sie die Server-URL ein: https://sora.mcp.acedata.cloud/mcp
Schließen Sie den OAuth-Login-Prozess ab
Beginnen Sie mit der Nutzung der Tools in Ihrer Konversation
Fügen Sie dies zu Ihrer Konfiguration hinzu (~/Library/Application Support/Claude/claude_desktop_config.json unter macOS):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu Ihrer MCP-Konfiguration hinzu (.cursor/mcp.json oder .windsurf/mcp.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu Ihrer VS Code MCP-Konfiguration hinzu (.vscode/mcp.json):
{
"servers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Oder installieren Sie die Ace Data Cloud MCP-Erweiterung für VS Code, die alle 15 MCP-Server mit einer Ein-Klick-Einrichtung bündelt.
Gehen Sie zu Einstellungen → Tools → AI Assistant → Model Context Protocol (MCP)
Klicken Sie auf Hinzufügen → HTTP
Einfügen:
{
"mcpServers": {
"sora": {
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Claude Code unterstützt MCP-Server nativ:
claude mcp add sora --transport http https://sora.mcp.acedata.cloud/mcp \
-h "Authorization: Bearer YOUR_API_TOKEN"Oder fügen Sie es zur .mcp.json Ihres Projekts hinzu:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu den MCP-Einstellungen von Cline hinzu (.cline/mcp_settings.json):
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu Ihrer MCP-Konfiguration hinzu:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu den Roo Code MCP-Einstellungen hinzu:
{
"mcpServers": {
"sora": {
"type": "streamable-http",
"url": "https://sora.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Fügen Sie dies zu .continue/config.yaml hinzu:
mcpServers:
- name: sora
type: streamable-http
url: https://sora.mcp.acedata.cloud/mcp
headers:
Authorization: "Bearer YOUR_API_TOKEN"Fügen Sie dies zu den Einstellungen von Zed hinzu (~/.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"}}}'Wenn Sie den Server lieber auf Ihrem eigenen Rechner ausführen möchten:
# 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 verbinden sich mit ihrem eigenen Bearer-Token — der Server extrahiert das Token aus dem Authorization-Header jeder Anfrage.
Tool | Beschreibung |
| Generiert Video aus einem Text-Prompt |
| Generiert Video aus Referenzbildern |
| Generiert Video mit einem Charakter aus einem Referenzvideo |
| Generiert Video mit Callback-Benachrichtigung |
Tool | Beschreibung |
| Fragt den Status einer einzelnen Aufgabe ab |
| Fragt mehrere Aufgaben gleichzeitig ab |
Tool | Beschreibung |
| Listet verfügbare Sora-Modelle auf |
| Listet verfügbare API-Aktionen auf |
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]Modell | Maximale Dauer | Qualität | Funktionen |
| 15 Sekunden | Gut | Standardgenerierung |
| 25 Sekunden | Beste | Höhere Qualität, längere Videos |
Größe:
small - Niedrigere Auflösung, schnellere Generierung
large - Höhere Auflösung (empfohlen)
Ausrichtung:
landscape - 16:9 (YouTube, Präsentationen)
portrait - 9:16 (TikTok, Instagram Stories)
Dauer:
10 Sekunden - Alle Modelle
15 Sekunden - Alle Modelle
25 Sekunden - Nur sora-2-pro
Variable | Beschreibung | Standard |
| API-Token von AceDataCloud | Erforderlich |
| API-Basis-URL |
|
| OAuth-Client-ID (gehosteter Modus) | — |
| Plattform-Basis-URL |
|
| Standardmodell |
|
| Standard-Videogröße |
|
| Standarddauer (Sekunden) |
|
| Standardausrichtung |
|
| Anfrage-Timeout (Sekunden) |
|
| 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.mdDieser Server umschließt die AceDataCloud Sora API:
Sora Videos API - Videogenerierung
Sora Tasks API - Aufgabenabfragen
Beiträge sind willkommen! Bitte:
Forken Sie das Repository
Erstellen Sie einen Feature-Branch (git checkout -b feature/amazing)
Committen Sie Ihre Änderungen (git commit -m 'Add amazing feature')
Pushen Sie auf den Branch (git push origin feature/amazing)
Öffnen Sie einen Pull Request
MIT-Lizenz - siehe LICENSE für Details.
Mit Liebe gemacht von 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.
